Lập trình giao diện hướng dữ liệu

Có một phần cơ sở mã của chúng tôi được viết theo phong cách sau:

// IScheduledTask.cs
public interface IScheduledTask
{
    string TaskName { get; set; }
    int TaskPriority { get; set; }
    List<IScheduledTask> Subtasks { get; set; }
    // ... several more properties in this vein
}

// ScheduledTaskImpl.cs
public class ScheduledTaskImpl : IScheduledTask
{
    public string TaskName { get; set; }
    public int TaskPriority { get; set; }
    public List<IScheduledTask> Subtasks { get; set; }
    // ... several more properties in this vein, 
    // perhaps a constructor or two for convenience.
}

Đó là, có một số lượng lớn các giao diện chỉ định một tập các thuộc tính không có hành vi nào với mỗi thực hiện tương ứng duy nhất thực hiện các giao diện này với các thuộc tính tự động. Mã được viết bởi một người khá cao cấp (nhiều hơn tôi) và ngoài việc sử dụng giao diện mã thủ tục hợp lý này. Tôi đã tự hỏi nếu có ai khác đã gặp / sử dụng phong cách này và liệu nó có bất kỳ lợi thế nào so với việc chỉ sử dụng các DTO cụ thể ở mọi nơi mà không có giao diện.

Đây là hai xu của tôi:

• Chúng tôi không chắc chắn một DTO sẽ không bao giờ có ít nhất một chút hành vi. Vì vậy, đối với tôi có những đối tượng có thể có hoặc không có hành vi trong tương lai.
• Một nguyên nhân có thể của việc có rất nhiều lớp học duy nhất-thực hiện là một thiếu thiết kế , ví dụ thất bại để thấy rằng ScheduledTask, ScheduledJob, ScheduledEvent, ScheduledInspection, vv, nên chỉ có một tách biệt Schedulablegiao diện thực hiện bất kỳ schedulable implementor.
• Tạo các giao diện đầu tiên là một thực hành rất tốt, nó cung cấp cho bạn cái nhìn sâu sắc về những gì bạn cần. Nhiều giao diện bắt đầu bằng cách không có triển khai nào cả. Sau đó, một người nào đó viết một thực hiện và họ có cái đó. Tình trạng có một triển khai duy nhất là tạm thời nếu bạn tránh những gì tôi đề cập trong điểm thứ hai. Làm thế nào để bạn biết trước rằng một số giao diện sẽ không bao giờ có lần thứ hai thực hiện thứ ba?
• Tên chúng tôi chọn cho giao diện được suy nghĩ kỹ có xu hướng không thay đổi trong tương lai, vì vậy phụ thuộc vào giao diện đó sẽ không bị ảnh hưởng. Mặt khác, một lớp cụ thể dễ bị đổi tên khi một thứ quan trọng trong cách thực hiện thay đổi, ví dụ một lớp cụ TaxSheetthể có tên có thể thay đổi SessionAwareTaxSheetvì một đại tu đáng kể đã được thực hiện nhưng giao diện ITaxSheetcó thể sẽ không được đổi tên dễ dàng như vậy.

Dòng dưới cùng:

• Thực hành thiết kế tốt cũng áp dụng cho DTOs.
• DTO có thể được thêm một chút hành vi xuống đường.
• Mỗi giao diện bắt đầu bằng cách chỉ có một thực hiện.
• Mặt khác, nếu bạn có quá nhiều combo một giao diện một lớp, có thể thiếu thiết kế nên được chỉ ra. Preocupation của bạn có thể được biện minh .

Một vấn đề cụ thể tôi đã thấy với các DTO sử dụng giao diện là nó cho phép điều này:

public interface ISomeDTO { string SomeProperty { get; set; }}

public class SomeDTO : ISomeDTO
{
    public string SomeProperty { get; set; }
    string ISomeDTO.SomeProperty { get { /* different behavior */ } set { SomeProperty = value; } }
}

Tôi đã thấy mô hình này được áp dụng như một bản hack nhanh, bẩn để thực hiện một số hành vi quan trọng. Điều này dẫn đến mã có thể có hành vi rất khó hiểu:

SomeDTO a = GetSomeDTO();
ISomeDTO ia = a;
Assert.IsTrue(a.SomeProperty == ia.SomeProperty); // assert fails!

Điều này rất khó để duy trì và gây nhầm lẫn khi cố gắng gỡ rối hoặc tái cấu trúc. IMO, việc thêm hành vi vào DTO vi phạm nguyên tắc trách nhiệm duy nhất. Mục đích của DTO là thể hiện dữ liệu theo định dạng có thể được duy trì và phổ biến bởi một khung kiên trì.

DTO không phải là mô hình miền. Chúng ta không nên lo lắng nếu DTO bị thiếu máu. Để trích dẫn cuộc thảo luận của Martin Fowler về mô hình miền thiếu máu :

Cũng đáng nhấn mạnh rằng việc đưa hành vi vào các đối tượng miền không được mâu thuẫn với cách tiếp cận vững chắc của việc sử dụng phân lớp để tách logic miền khỏi những thứ như sự kiên trì và trách nhiệm trình bày.