Veri Odaklı Arabirimlere Programlama

Kod tabanımızın aşağıdaki tarzda yazılmış bir kısmı vardır:

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

Yani, her biri otomatik özelliklerle uygulayan tek bir karşılık gelen uygulama ile davranışsız bir dizi özelliği belirten çok sayıda arabirim vardır. Kod oldukça kıdemli biri tarafından yazılmıştır (kendimden çok daha fazla) ve arayüzlerin bu kullanımından makul prosedür kodu dışındadır. Başka kimsenin bu stille karşılaşıp karşılaşmadığını / kullanmış olup olmadığını ve sadece arayüzler olmadan her yerde beton DTO'ları kullanmanın herhangi bir avantajı olup olmadığını merak ediyordum.

İşte iki sentim:

• Bir DTO'nun asla en azından biraz davranış göstermeyeceğinden emin değiliz. Benim için gelecekte davranışları olan veya olmayan nesneler var.
• Pek çok taban-uygulama sınıfları sahip olası bir nedeni tasarım eksikliği olduğunu görmek için başarısız örneğin ScheduledTask, ScheduledJob, ScheduledEvent, ScheduledInspection, vb tek ayrılmış olmalıdır Schedulableherhangi implementor zamanlanabilen yapma arayüzü.
• İlk olarak arayüzler oluşturmak çok iyi bir uygulamadır, ihtiyacınız olan şey hakkında size fikir verir. Birçok arabirim hiç bir uygulamaya sahip olmadan başlar. Sonra birisi bir uygulama yazar ve buna sahiptir. İkinci noktada bahsettiğim şeyden kaçınırsanız, tek bir uygulamaya sahip olma durumu geçicidir. Bazı arayüzlerin hiçbir zaman üçüncü bir uygulamanın ikinci saniyesine sahip olmayacağını nereden biliyorsunuz?
• İyi düşünülmüş bir arayüz için seçtiğimiz adın gelecekte değişme eğilimi vardır, bu nedenle bu arayüze bağımlılıklar etkilenmez. Öte yandan, somut bir sınıf, uygulanma biçiminde önemli bir şey değiştiğinde yeniden adlandırılmaya eğilimlidir, örneğin, adlandırılmış bir somut sınıf , önemli bir revizyon yapıldığından TaxSheetdeğişebilir SessionAwareTaxSheet, ancak arayüz ITaxSheetmuhtemelen kolayca yeniden adlandırılmayacaktır.

Sonuç olarak:

• İyi tasarım uygulamaları DTO'lar için de geçerlidir.
• DTO'lar yolda biraz davranış ekleyebilir.
• Her arayüz sadece bir uygulamaya sahip olarak başlar.
• Öte yandan, çok fazla tek arayüzlü bir sınıf kombinasyonunuz varsa, dikkat edilmesi gereken bir tasarım eksikliği olabilir. Ön konuşmanız haklı olabilir .

Arabirim kullanan DTO'larda gördüğüm özel bir sorun, buna izin vermesidir:

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

Bu kalıbın bazı kritik davranışları uygulamak için hızlı, kirli bir saldırı olarak uygulandığını gördüm. Bu, çok kafa karıştırıcı davranışlara sahip olabilecek koda yol açar:

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

Bu çözülmeyi veya yeniden düzenlemeyi denemek için bakımı ve kafa karıştırıcı zordur. IMO, DTO'lara davranış eklemek tek sorumluluk ilkesini ihlal ediyor. Bir DTO'nun amacı, bir kalıcılık çerçevesi tarafından kalıcı ve doldurulabilecek bir formattaki verileri temsil etmektir.

DTO'lar alan modeli değildir. DTO'lar anemikse endişelenmemeliyiz. Martin Fowler'in anemik alan modeli hakkındaki tartışmasını alıntılamak için :

Etki alanı nesnelerine davranış koymanın, etki alanı mantığını kalıcılık ve sunum sorumlulukları gibi şeylerden ayırmak için katman kullanmanın katı yaklaşımıyla çelişmemesi gerektiğini de vurgulamak gerekir .