Bagaimana memperdebatkan pola pikir "sepenuhnya publik" tentang desain kelas objek bisnis ini

Kami melakukan banyak pengujian unit dan refactoring objek bisnis kami, dan saya tampaknya memiliki pendapat yang sangat berbeda tentang desain kelas daripada rekan-rekan lainnya.

Contoh kelas yang saya bukan penggemar:

public class Foo
{
    private string field1;
    private string field2;
    private string field3;
    private string field4;
    private string field5;

    public Foo() { }

    public Foo(string in1, string in2)
    {
        field1 = in1;
        field2 = in2;
    }

    public Foo(string in1, string in2, string in3, string in4)
    {
        field1 = in1;
        field2 = in2;
        field3 = in3;
    }

    public Prop1
    { get { return field1; } }
    { set { field1 = value; } }

    public Prop2
    { get { return field2; } }
    { set { field2 = value; } }

    public Prop3
    { get { return field3; } }
    { set { field3 = value; } }

    public Prop4
    { get { return field4; } }
    { set { field4 = value; } }

    public Prop5
    { get { return field5; } }
    { set { field5 = value; } }

}

Di kelas "nyata", mereka tidak semua string, tetapi dalam beberapa kasus kami memiliki 30 bidang dukungan untuk properti publik sepenuhnya.

Saya benci kelas ini, dan saya tidak tahu apakah saya hanya pilih-pilih. Beberapa hal yang perlu diperhatikan:

• Bidang dukungan pribadi tanpa logika di properti, tampaknya tidak perlu dan membengkak kelas
• Banyak konstruktor (agak ok) tetapi ditambah dengan
• semua properti memiliki setter publik, saya bukan penggemar.
• Secara potensial tidak ada properti yang akan diberi nilai karena konstruktor kosong, jika penelepon tidak mengetahui, Anda berpotensi mendapatkan beberapa yang sangat tidak diinginkan dan sulit untuk diuji perilaku.
• Terlalu banyak properti! (dalam 30 kasus)

Saya merasa jauh lebih sulit untuk benar - benar mengetahui keadaan objek Foosaat itu, sebagai pelaksana. Argumen dibuat "kita mungkin tidak memiliki informasi yang diperlukan untuk ditetapkan Prop5pada saat pembangunan objek. Ok, saya kira saya bisa mengerti itu, tetapi jika itu hanya membuat Prop5setter publik, tidak selalu hingga 30 properti di kelas.

Apakah saya hanya menjadi pemilih dan / atau gila karena menginginkan kelas yang "mudah digunakan" sebagai lawan dari "mudah untuk menulis (semuanya publik)"? Kelas-kelas seperti berteriak di atas kepada saya, saya tidak tahu bagaimana ini akan digunakan, jadi saya hanya akan membuat semuanya publik untuk berjaga-jaga .

Jika saya tidak terlalu pilih-pilih, argumen apa yang bagus untuk memerangi pemikiran seperti ini? Saya tidak pandai mengartikulasikan argumen, karena saya menjadi sangat frustrasi ketika mencoba menyampaikan pendapat saya (tentu saja tidak sengaja).

Kelas yang sepenuhnya publik memiliki pembenaran untuk situasi tertentu, dan juga yang ekstrem lainnya, kelas dengan hanya satu metode publik (dan mungkin banyak metode pribadi). Dan kelas dengan beberapa metode publik, beberapa pribadi juga.

Itu semua tergantung pada jenis abstraksi yang akan Anda modelkan dengan mereka, lapisan mana yang Anda miliki dalam sistem Anda, tingkat enkapsulasi yang Anda butuhkan di lapisan yang berbeda, dan (tentu saja) aliran pemikiran mana yang berasal dari kelas penulis dari. Anda dapat menemukan semua jenis ini dalam kode SOLID.

Ada seluruh buku yang ditulis tentang kapan harus memilih jenis desain, jadi saya tidak akan mencantumkan aturan apa pun di sini tentang hal itu, ruang di bagian ini tidak akan cukup. Namun, jika Anda memiliki contoh dunia nyata untuk abstraksi yang ingin Anda modelkan dengan sebuah kelas, saya yakin komunitas di sini dengan senang hati akan membantu Anda untuk meningkatkan desain.

Untuk membahas poin Anda yang lain:

• "bidang dukungan pribadi tanpa logika di properti": Ya, Anda benar, untuk getter dan setter sepele ini hanya "noise" yang tidak perlu. Untuk menghindari "bloat" semacam ini, C # memiliki sintaks pintas untuk metode get / set properti:

Jadi, bukannya

   private string field1;
   public string Prop1
   { get { return field1; } }
   { set { field1 = value; } }

menulis

   public string Prop1 { get;set;}

atau

   public string Prop1 { get;private set;}

• "Beberapa konstruktor": itu bukan masalah. Itu mendapat masalah ketika ada duplikasi kode yang tidak perlu di sana, seperti ditunjukkan dalam contoh Anda, atau hirarki panggilan berbelit-belit. Ini dapat dengan mudah diselesaikan dengan refactoring bagian-bagian umum menjadi fungsi yang terpisah, dan dengan mengatur rantai konstruktor secara searah

• "Secara potensial tidak ada properti yang akan diberi nilai karena konstruktor kosong": dalam C #, setiap tipe data memiliki nilai default yang jelas. Jika properti tidak diinisialisasi secara eksplisit dalam konstruktor, mereka mendapatkan nilai default ini ditetapkan. Jika ini digunakan dengan sengaja , itu benar-benar oke - jadi konstruktor kosong mungkin ok jika penulis tahu apa yang dia lakukan.

• "Terlalu banyak properti! (Dalam 30 kasus)": ya, jika Anda bebas merancang kelas seperti itu dengan cara greenfield, 30 terlalu banyak, saya setuju. Namun, tidak semua dari kita memiliki kemewahan ini (bukankah Anda menulis di komentar di bawah ini adalah sistem warisan?). Terkadang Anda harus memetakan catatan dari database yang ada, atau file, atau data dari API pihak ketiga ke sistem Anda. Jadi untuk kasus-kasus ini, 30 atribut mungkin sesuatu yang harus dijalani seseorang.

1. Dengan mengatakan bahwa "Bidang dukungan pribadi tanpa logika di properti, tampaknya tidak perlu dan membesar-besarkan kelas" Anda sudah memiliki argumen yang layak.

2. Sepertinya bukan beberapa konstruktor yang menjadi masalah di sini.

3. Sedangkan untuk memiliki semua properti sebagai publik ... Mungkin pikirkan seperti ini, jika Anda ingin menyinkronkan akses ke semua properti ini di antara utas Anda akan mengalami kesulitan karena Anda mungkin harus menulis kode sinkronisasi di mana pun mereka berada bekas. Namun, jika semua properti tertutup oleh getter / setter maka Anda dapat dengan mudah membangun sinkronisasi ke dalam kelas.

4. Saya pikir ketika Anda mengatakan "sulit untuk menguji perilaku" argumen itu berbicara sendiri. Tes Anda mungkin harus memeriksa apakah bukan nol atau sesuatu seperti itu (setiap tempat digunakan properti). Saya tidak benar-benar tahu karena saya tidak tahu seperti apa tes / aplikasi Anda.

5. Anda benar terlalu banyak properti, dapatkah Anda mencoba menggunakan pewarisan (jika propertinya cukup mirip) dan kemudian memiliki daftar / array menggunakan obat generik? Kemudian Anda bisa menulis getter / setter untuk mengakses informasi dan menyederhanakan cara Anda akan berinteraksi semua properti.

Seperti yang Anda katakan, Fooadalah objek bisnis. Itu harus merangkum beberapa perilaku dalam metode sesuai dengan domain Anda dan datanya harus tetap dienkapsulasi mungkin.

Pada contoh yang Anda tunjukkan, Foolebih mirip DTO dan bertentangan dengan semua prinsip OOP (lihat Model Domain Anemik )!

Sebagai perbaikan saya sarankan:

• Jadikan kelas ini sebagai abadi mungkin. Seperti yang Anda katakan, Anda ingin membuat beberapa pengujian unit. Salah satu kemampuan wajib untuk pengujian unit adalah determinisme , dan determinisme dapat dicapai melalui ketidakmampuan karena itu memecahkan masalah efek samping .
• Hancurkan kelas dewa ini menjadi beberapa kelas yang masing-masing hanya melakukan 1 hal (lihat SRP ). Unit menguji 30 atribut kelas dalam benar-benar PITA .
• Hapus redundansi konstruktor dengan hanya memiliki 1 konstruktor utama dan yang lainnya memanggil konstruktor utama.
• Hapus getter yang tidak perlu, saya benar-benar ragu semua getter benar-benar bermanfaat.
• Kembalikan logika bisnis di kelas bisnis, di sinilah tempatnya!

Ini bisa menjadi kelas refactored potensial dengan komentar ini:

public sealed class Foo
{
    private readonly string field1;
    private readonly string field2;
    private readonly string field3;
    private readonly string field4;

    public Foo() : this("default1", "default2")
    { }

    public Foo(string in1, string in2) : this(in1, in2, "default3", "default4")
    { }

    public Foo(string in1, string in2, string in3, string in4)
    {
        field1 = in1;
        field2 = in2;
        field3 = in3;
        field4 = in4;
    }

    //Methods with business logic

    //Really needed ?
    public Prop1
    { get; }

    //Really needed ?
    public Prop2
    { get; }

    //Really needed ?
    public Prop3
    { get; }

    //Really needed ?
    public Prop4
    { get; }

    //Really needed ?
    public Prop5
    { get; }
}

Bagaimana memperdebatkan pola pikir "sepenuhnya publik" tentang desain kelas objek bisnis ini

• "Ada beberapa metode yang tersebar di kelas klien melakukan lebih dari 'tugas DTO belaka'. Mereka milik bersama."
• "Ini mungkin 'DTO' tetapi memiliki identitas bisnis - kita perlu mengesampingkan Persamaan."
• "Kita perlu mengurutkan ini - kita perlu mengimplementasikan IComparable"
• "Kami merangkai beberapa properti ini. Mari kita menimpa ToString sehingga setiap klien tidak harus menulis kode ini."
• "Kami memiliki banyak klien yang melakukan hal yang sama ke kelas ini. Kami perlu MENINGGALKAN kodenya."
• "Klien memanipulasi koleksi hal-hal ini. Jelas itu seharusnya kelas koleksi kustom; dan banyak poin sebelumnya akan membuat koleksi kustom lebih fungsional daripada saat ini."
• "Lihat semua manipulasi string yang membosankan, terbuka, dan merangkum bahwa dalam metode yang relevan dengan bisnis akan meningkatkan produktivitas pengkodean kami."
• "Menarik metode ini bersama-sama ke dalam kelas akan membuatnya dapat diuji karena kita tidak harus berurusan dengan kelas klien yang lebih kompleks."

• "Kita sekarang dapat menguji unit metode refactored itu. Karena, untuk alasan x, y, z klien tidak dapat diuji.

• Sejauh argumen di atas dapat dibuat, secara agregat:

  • The fungsi menjadi dapat digunakan kembali.
  • KERING
  • Ini dipisahkan dari klien.
  • pengkodean terhadap kelas lebih cepat dan lebih sedikit kesalahan.
• "Kelas yang dilakukan dengan baik menyembunyikan status dan memperlihatkan fungsionalitas. Ini adalah proposisi awal untuk merancang kelas OO."
• "Hasil akhir melakukan pekerjaan yang jauh lebih baik dalam mengekspresikan domain bisnis; entitas yang berbeda dan interaksi eksplisit mereka."
• "Fungsionalitas 'overhead' ini (yaitu bukan persyaratan fungsional eksplisit, tetapi harus dilakukan) jelas menonjol dan menganut Prinsip Tanggung Jawab Tunggal.