ID doanh nghiệp nổi tiếng của một thực thể có nên được trình bày bằng một loại chuyên dụng trong DDD / OOP không?

9

Trong thực tế, điều đó có nghĩa là sử dụng một tùy chỉnh (không thay đổi) classđối với một stringhoặc một số loại nguyên thủy khác.

Ví dụ:

Xuất bản: Số sách tiêu chuẩn quốc tế.
Tài chính: Số nhận dạng chứng khoán quốc tế.

Ưu điểm:

Có thể đảm bảo định dạng của một định danh.
Trở thành thành viên hạng nhất của mô hình.

Nhược điểm:

Thêm ma sát bền bỉ (ví dụ Entity Framework).
Thêm mã.

— Den
nguồn

Bạn có nên sử dụng một lớp tùy chỉnh? Chắc chắn rồi. Bạn có nên sử dụng chúng làm ID? Hoàn toàn không :) Một ID có ý nghĩa kinh doanh sẽ gây rắc rối trên đường đi.

— Songo

2

@Songo Đối với tôi đó là một lập luận rằng ID nên có ngữ nghĩa giá trị , nhưng các kiểu nguyên thủy không phải là loại duy nhất có ngữ nghĩa giá trị, do đó không nhất thiết loại trừ các lớp imo. Vui lòng gửi câu trả lời cạnh tranh mặc dù tôi đã quên đưa ra quan điểm đó.

— Ixrec

1

Một câu hỏi cũ của tôi đã chạm vào chủ đề này với các ý kiến khác nhau: lập trình viên.stackexchange.com / questions / 2181827 / Tôi đã đi với việc tạo các loại và tiếp tục làm như vậy.

— Ziv

6

Nếu bạn có thể cung cấp cho lớp đủ chức năng hữu ích để chứng minh sự phức tạp thêm vào của việc không phải là một chuỗi, thì hãy làm điều đó. Đối với các định danh như ISBN và ISIN, tôi nghi ngờ đây không phải là trường hợp.

Để một lớp định danh trở nên hữu ích, tôi hy vọng nó sẽ trông giống như thế này:

class ISIN {
    fromCUSIP()
    fromRawISINString()
    toString(ISIN::FormatType)
    getExchange()
    getCountryCode()
    getLastFourDigits()
    getWhateverCode()
    ...
}

Nếu thay vào đó, nó trông giống như thế này:

class ISIN {
    getString()
    setString()
}

Sau đó, tôi sẽ bỏ lớp hoàn toàn, sử dụng các chuỗi thông thường ở mọi nơi và đảm bảo rằng tôi luôn sử dụng "isin" trong tất cả các tên biến có liên quan.

Lưu ý rằng trong một số ngôn ngữ, việc thêm một loại mới hầu như không có "độ phức tạp thêm" trong các chương trình thông thường, trong trường hợp đó, bạn được khuyến khích tạo loại mới ngay cả khi nó không có chức năng nào cả. Nhưng đây không phải là trường hợp của hầu hết các ngôn ngữ OOP truyền thống như C ++.

— Ý kiến
nguồn

6

Tôi sẽ nói đi cho nó. Tôi sẽ lập luận rằng những ưu điểm vượt trội hơn những nhược điểm trong trường hợp này. Mã bổ sung có thể khá nhỏ và vấn đề tồn tại có thể được giải quyết khá dễ dàng khi cung cấp một số loại trình chuyển đổi giữa Lớp mới của bạn và loại cơ sở dữ liệu mong đợi (Tôi chưa bao giờ sử dụng Entity Framework nhưng tôi biết điều này tương đối không gây đau đớn Ngủ đông).

Một trong những lợi thế bạn có thể nhận được bằng cách xác định lớp của riêng mình là trình biên dịch có thể đảm bảo rằng bất kỳ phương thức nào muốn có mã số hoặc ISIN sẽ biết vào thời gian biên dịch nếu bạn thử và chuyển sai giá trị. Việc vô tình ghi đè lên trường đó trong thực thể của bạn cũng sẽ khó hơn nhiều. Chúng ta có thể tránh các lỗi phổ biến như thế này hoàn toàn:

book.setAuthor(otherBook.getAuthorName());
book.setIsbn(otherBook.getAuthorName());
book.setPrice(otherBook.getPrice())

Nếu ISBN là một lớp chứ không phải là kiểu nguyên thủy thì đoạn mã trên sẽ không được biên dịch, tiết kiệm rất nhiều thời gian gỡ lỗi sau này.

— Matt Watson
nguồn

1

setters và getters? Có phải là năm 1992 không?

— Tuyến Miles