Giải pháp thay thế cho một hệ thống phân cấp thừa kế sâu?

Question

Tôi đang cố gắng lập mô hình các sản phẩm với một tập hợp các thuộc tính toàn diện. Thông thường, một cửa hàng trực tuyến sẽ sử dụng mô tả văn bản để liệt kê các thuộc tính của một sản phẩm cụ thể. Tuy nhiên, giải pháp này không phải là tối ưu.

Ví dụ, các liên kết sau đây cho thấy những mâu thuẫn của các thuộc tính trong một mô tả văn bản cho cùng một sản phẩm, nhưng với các nhà sản xuất khác nhau:

• MSI GTX690
• Gigabyte GTX690
• ASUS GTX690

Do đó, tôi đã chọn một hệ thống phân cấp thừa kế như sau:

Product>Component>GraphicsCard>NvidiaGraphicsCard

Lý do cho điều này là bởi vì tôi muốn kiểm soát hạt mịn trên các thuộc tính của mỗi Product. Điều này cho phép tôi bao gồm các thuộc tính cụ thể để nói một số NvidiaGraphicsCard không áp dụng cho một số ATiGraphicsCard.

Lưu ý rằng ngoài việc thêm nhiều trường vào lớp con, thừa kế cho phép tôi sử dụng đa hình về việc có một số OrderItem giữ tham chiếu đến Product. Đây là một lý do tại sao tôi loại trừ thành phần.

Có vấn đề gì khi có một hệ thống phân cấp thừa kế sâu sắc như vậy và nếu có thì có giải pháp hoặc có lẽ các mẫu để xử lý vấn đề này không?

Answer 1

Phân cấp thừa kế sâu có vấn đề trong ngữ cảnh DDD và ORM vì một vài lý do. Một vấn đề nảy sinh khi bạn cố gắng xác định danh tính của một thực thể. A Product phải được so sánh với các sản phẩm khác dựa trên danh tính, bất kể phân loại nào được so sánh. Chức năng này có thể được cung cấp trong lớp Product, nhưng cần phải cẩn thận để đảm bảo rằng các lớp con cũng có thể được so sánh và có một vài trường hợp. Ví dụ, NHibernate sẽ tạo ra một proxy cho các lớp, do đó kiểu thời gian thực tế của đối tượng sẽ không phải là NvidiaGraphicsCard mà là một proxy kế thừa từ nó. Mặc dù phiên bản tạm thời của NvidiaGraphicsCard sẽ không phải là proxy. Điều này có nghĩa là bạn không thể so sánh chúng dựa trên loại.

Khó khăn khác là định cấu hình ánh xạ ORM để hỗ trợ kế thừa. Trong khi hầu hết các ORM cho phép, thì việc ánh xạ kết quả và các SQL được tạo ra thường phức tạp. Bạn có lưu trữ tất cả các lớp con trong một bảng không? Trong nhiều bảng có khóa ngoài đến một bảng sản phẩm chung? Trước đây bạn kết thúc với một cái bàn lớn. Trong trường hợp sau, truy vấn của bạn sẽ bị ảnh hưởng vì tất cả các bảng lớp phụ sẽ cần phải được tham gia. Chỉ có quá nhiều sự không phù hợp trở kháng giữa mô hình quan hệ và mô hình đối tượng. Sự kiện nếu sử dụng cơ sở dữ liệu tài liệu, tốt nhất là nên ưu tiên thành phần trên thừa kế.

Thay vào đó, tôi sẽ có một lớp Product duy nhất, có thể bao gồm mô tả cụ thể của sản phẩm hoặc từ điển thuộc tính. Điều này sẽ là OrderItem để tham chiếu Product mà không biết loại sản phẩm cụ thể - không cần đa hình. Điều này cũng sẽ giúp việc cho phép các loại sản phẩm mới trở nên dễ dàng hơn - không cần phải tạo một lớp con mới.

Answer 2

Đó là ví dụ về sách kế thừa trường học, một ví dụ điển hình. Tôi thấy không có gì sai với mô hình như vậy, ngoại trừ việc kiên trì nó trong cơ sở dữ liệu quan hệ sẽ khó.

Mặt khác đôi khi một nhóm thuộc tính chỉ liên quan đến một tập hợp con các mục không thể được biểu thị thông qua kế thừa đơn. Ví dụ. PowerConsumption mô tả nhu cầu của sản phẩm được cung cấp bao nhiêu năng lượng không liên quan đến chuột và thanh USB. Trọng lượng cũng không thực sự quan trọng đối với một số thành phần. Điều này có nghĩa là bạn có thể điều tra các ngôn ngữ có các đặc điểm, như Scala, để làm cho các mô hình của bạn càng khô càng tốt. Lưu ý rằng không có hình phạt hiệu suất của thừa kế sâu - chuỗi kế thừa dài hơn không có nghĩa là các cuộc gọi phương thức ảo chậm hơn (tốt, bạn sẽ không sử dụng nhiều cuộc gọi ảo vì đây chỉ là các vùng chứa dữ liệu).

Answer 3

Tôi khuyên bạn nên xem mẫu trang trí. Bằng cách này bạn sẽ có bất kỳ sự khéo léo nào bạn cần và ít hơn một tỷ lớp.