Програмування до інтерфейсів, орієнтованих на дані

Є частина нашої кодової бази, написана у такому стилі:

// 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.
}

Тобто, існує велика кількість інтерфейсів, що вказують лише набір властивостей, без поведінки, кожен з єдиною відповідною реалізацією, яка реалізує їх з автоматичними властивостями. Код пише хтось досить старший (набагато більше, ніж я), і крім цього використання інтерфейсів є розумним процесуальним кодом. Мені було цікаво, чи стикався хтось із хтось / використовував цей стиль і чи має він переваги перед просто використанням конкретних DTO скрізь без інтерфейсів.

Ось два мої центи:

• Ми не впевнені, що у DTO ніколи не буде принаймні трохи поведінки. Тож для мене є предмети, які можуть чи не можуть мати поведінку в майбутньому.
• Однією з можливих причин того, так багато класів єдиною реалізації є відсутністю дизайну , наприклад , НЕ бачити , що ScheduledTask, ScheduledJob, ScheduledEvent, ScheduledInspectionі т.д., має бути тільки один відокремлені Schedulableінтерфейс робить будь-який реалізатор запланованим.
• Створення інтерфейсів спочатку - дуже хороша практика, вона дає вам уявлення про те, що вам потрібно. Багато інтерфейсів починаються з того, що вони взагалі не мають реалізації. Потім хтось пише одну реалізацію, і у неї є така. Стан єдиної реалізації є тимчасовим, якщо ви уникаєте того, що я згадую у другому пункті. Як ви заздалегідь знаєте, що якийсь інтерфейс ніколи не матиме секунди третьої реалізації?
• Ім'я, яке ми обираємо для продуманого інтерфейсу, має тенденцію не змінюватись у майбутньому, тому залежність від цього інтерфейсу не вплине. З іншого боку, конкретний клас схильний перейменовуватися, коли щось важливе в способі його реалізації змінюється, наприклад, конкретний клас, названий TaxSheetможе змінитися, SessionAwareTaxSheetоскільки був зроблений значний капітальний ремонт, але інтерфейс ITaxSheet, ймовірно, не буде перейменований так легко.

Нижня лінія:

• Гарні дизайнерські практики застосовуються також до DTO.
• DTO може бути додано трохи поведінки в дорозі.
• Кожен інтерфейс починається лише з однієї реалізації.
• З іншого боку, якщо у вас занадто багато комбінацій одного інтерфейсу та одного класу, може бути брак дизайну, на який слід звернути увагу. Ваша зайнятість може бути виправданою .

Особлива проблема, яку я бачив із DTO, які використовують інтерфейси, полягає в тому, що це дозволяє:

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; } }
}

Я бачив, що ця модель застосовується як швидкий, брудний злом для реалізації критичної поведінки. Це призводить до коду, який може мати дуже заплутану поведінку:

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

Це важко підтримувати і заплутати, щоб спробувати розкрутити чи відреагувати. IMO, додаючи поведінку до DTO, порушує принцип єдиної відповідальності. Метою DTO є представлення даних у форматі, який можна зберігати та заповнювати за допомогою системи збереження.

DTO не є доменними моделями. Ми не повинні бути стурбовані, якщо ДТО є анемічними. Щоб процитувати обговорення Мартіна Фаулера про анемічну модель домену :

Варто також підкреслити, що введення поведінки в об’єкти домену не повинно суперечити твердому підходу використання шарів, щоб відокремити логіку домену від таких речей, як наполегливість та обов'язки презентації.