Pemrograman untuk Antarmuka Berorientasi Data

Ada sebagian basis kode kami yang ditulis dengan gaya berikut:

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

Yaitu, ada sejumlah besar antarmuka yang menetapkan hanya satu set properti tanpa perilaku masing-masing dengan satu-satunya implementasi yang sesuai yang mengimplementasikannya dengan properti-otomatis. Kode ini ditulis oleh seseorang yang cukup senior (lebih dari saya) dan terlepas dari penggunaan antarmuka ini, kode prosedural yang masuk akal. Saya bertanya-tanya apakah ada orang lain yang mengalami / menggunakan gaya ini dan apakah itu memiliki kelebihan dibandingkan hanya menggunakan DTO beton di mana-mana tanpa antarmuka.

— walpen
sumber

Salah satu alasan saya melakukan itu adalah untuk kompatibilitas COM, tetapi sepertinya itu bukan alasan Anda di sini.

— Mike

@ Mike Menarik, saya tidak pernah menggunakan COM dan tidak digunakan di sini. Saya akan bertanya kepada penulis bagian kode ini apakah dia berencana untuk menggunakan COM atau apa pun.

— walpen

Dugaan saya adalah bahwa ia berharap untuk membuat setidaknya satu dari properti-properti tersebut non-otomatis dalam waktu yang relatif dekat, dan menulis pelat tungku ini pada awalnya adalah kebiasaan yang ia lakukan untuk menghemat waktu bermain-main nanti, meskipun saya bukan pria C # jadi itu yang bisa saya katakan.

— Ixrec

IMHO itu adalah obsesi berlebihan dan penerapan kode yang salah pada antarmuka bukan implementasi . Kisah kunci adalah implementasi satu-satunya . Titik antarmuka adalah polimorfisme tetapi kelas properti-saja bersifat polimorfik dalam arti hanya dengan memiliki nilai yang berbeda. Bahkan dengan perilaku - metode - tidak ada gunanya diberikan implementasi tunggal. Omong kosong ini ada di seluruh basis kode kami dan paling tidak menghambat pemeliharaan. Saya terlalu banyak membuang waktu untuk bertanya mengapa, apa, dan di mana. Mengapa mereka melakukannya, desain apa yang tidak saya lihat, dan di mana implementasi lainnya?

— radarbob

Sebagian besar komentar sebelumnya pergi ke "kode bau" implementasi tunggal abstraksi prematur; namun, ada juga model domain anemik "bau kode" di sini, lihat: martinfowler.com/bliki/AnemicDomainModel.html

— Erik Eidt

Jawaban:

Inilah dua sen saya:

Kami tidak yakin DTO tidak akan pernah memiliki setidaknya sedikit perilaku. Jadi bagi saya ada objek yang mungkin atau mungkin tidak memiliki perilaku di masa depan.
Salah satu kemungkinan penyebab memiliki begitu banyak kelas tunggal implementasi adalah kurangnya desain , misalnya gagal untuk melihat bahwa ScheduledTask, ScheduledJob, ScheduledEvent, ScheduledInspection, dll, harus hanya satu dipisahkan Schedulableantarmuka membuat setiap implementor schedulable.
Membuat antarmuka terlebih dahulu adalah praktik yang sangat baik, ini memberi Anda wawasan tentang apa yang Anda butuhkan. Banyak antarmuka dimulai dengan tidak memiliki implementasi sama sekali. Kemudian seseorang menulis satu implementasi dan mereka memilikinya. Keadaan memiliki implementasi tunggal bersifat sementara jika Anda menghindari apa yang saya sebutkan di poin kedua. Bagaimana Anda tahu sebelumnya bahwa beberapa antarmuka tidak akan pernah memiliki kedua implementasi ketiga?
Nama yang kami pilih untuk antarmuka yang dipikirkan dengan baik memiliki kecenderungan untuk tidak berubah di masa mendatang, jadi ketergantungan pada antarmuka tersebut tidak akan terpengaruh. Di sisi lain kelas konkret cenderung diganti namanya ketika sesuatu yang penting dalam mengimplementasikan perubahan, misalnya kelas konkret bernama TaxSheetdapat berubah SessionAwareTaxSheetkarena perbaikan yang signifikan dibuat tetapi antarmuka ITaxSheetmungkin tidak akan diganti nama dengan mudah.

Intinya:

Praktik desain yang baik berlaku juga untuk DTO.
DTO dapat ditambahkan sedikit perilaku di jalan.
Setiap antarmuka dimulai dengan hanya memiliki satu implementasi.
Di sisi lain, jika Anda memiliki terlalu banyak kombo satu antarmuka satu kelas, mungkin ada kekurangan desain yang harus ditunjukkan. Preokupasi Anda dapat dibenarkan .

— Tulains Córdova
sumber

Saya mengubah jawaban Anda, tetapi butir kedua Anda menyiratkan bahwa semua kelas harus secara otomatis memiliki antarmuka yang sesuai, posisi yang tidak pernah saya setujui. Menulis antarmuka jika Anda mungkin memiliki implementasi kedua hanya menyebabkan proliferasi antarmuka, dan YAGNI.

— Robert Harvey

Masalah khusus yang saya lihat dengan DTO yang menggunakan antarmuka adalah memungkinkannya:

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

Saya telah melihat pola ini diterapkan sebagai peretasan cepat dan kotor untuk menerapkan beberapa perilaku kritis. Ini mengarah ke kode yang dapat memiliki perilaku yang sangat membingungkan:

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

Hal ini sulit untuk dipertahankan dan membingungkan untuk dicoba dilepaskan atau diolah. IMO, menambahkan perilaku ke DTO melanggar prinsip tanggung jawab tunggal. Tujuan dari DTO adalah untuk merepresentasikan data dalam format yang dapat dipertahankan dan diisi oleh kerangka persistensi.

DTO bukan model domain. Kita seharusnya tidak khawatir jika DTO anemia. Mengutip diskusi Martin Fowler tentang model domain anemik :

Perlu juga ditekankan bahwa menempatkan perilaku ke objek domain tidak boleh bertentangan dengan pendekatan solid menggunakan layering untuk memisahkan logika domain dari hal-hal seperti ketekunan dan tanggung jawab presentasi.

— Erik
sumber