İş nesnesi sınıfı tasarımın bu “tamamen halka açık” zihniyetine nasıl karşı çıkılır?

İş nesnelerimiz üzerinde çok sayıda birim testi ve yeniden düzenleme yapıyoruz ve sınıf tasarımı konusunda diğer akranlardan çok farklı görüşlere sahibim .

Ben hayranı değilim örnek bir sınıf:

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

}

"Gerçek" sınıfta, hepsi dize değildir, ancak bazı durumlarda tamamen herkese açık mülkler için 30 destek alanımız vardır.

Ben nefret Bu sınıf, ve ben sadece seçici davranıyorum eğer bilmiyorum. Dikkat edilmesi gereken birkaç nokta:

• Özelliklerde mantığı olmayan özel destek alanları gereksiz görünüyor ve sınıfı şişiriyor
• Birden fazla kurucu (biraz iyi) ancak
• tüm özellikleri bir kamu ayarlayıcı sahip, ben bir hayran değilim.
• Potansiyel olarak boş bir yapıcı nedeniyle hiçbir özelliğe değer atanmaz, bir arayan farkında değilse potansiyel olarak çok istenmeyen ve davranışlarını test etmek zor olabilir.
• Çok fazla özellik var! (30 vakada)

Herhangi bir zamanda, bir uygulayıcı olarak nesnenin hangi durumda olduğunu gerçekten bilmek çok daha zor Foo. Argüman " Prop5nesne yapımı sırasında ayarlamak için gerekli bilgiye sahip olmayabiliriz . Tamam, sanırım bunu anlayabiliyorum, ama eğer durum buysa Prop5, her zaman bir sınıfta en fazla 30 mülkü değil, sadece ayarlayıcıyı herkese açık hale getirin .

"Yazması kolay (herkese açık)" olmanın aksine "kullanımı kolay" bir sınıf istemek için nit seçici ve / veya çılgın mıyım? Yukarıdaki gibi sınıflar bana çığlık atıyor, bunun nasıl kullanılacağını bilmiyorum, bu yüzden her ihtimale karşı her şeyi herkese açık hale getireceğim .

Çok seçici davranmıyorsam, bu tür düşüncelerle mücadele etmek için iyi argümanlar nelerdir? Tartışmaları açıklamakta çok iyi değilim, çünkü kastettiğim noktaya değinmeye çalışırken çok sinirliyim (kasıtlı olarak değil).

Tamamen kamu sınıfları, belirli durumlar için ve diğer uç noktalarda, sadece tek bir kamusal yöntemle (ve muhtemelen birçok özel yöntemle) bir gerekçeye sahiptir. Ve bazı kamuya açık, bazı özel yöntemlerle dersler.

Her şey onlarla modelleyeceğiniz soyutlama türüne, sisteminizde hangi katmanlara sahip olduğunuza, farklı katmanlarda ihtiyacınız olan kapsülleme derecesine ve (elbette) sınıfın yazarının hangi düşünce okulunun geldiğine bağlıdır. dan. Bu türlerin tümünü SOLID kodunda bulabilirsiniz.

Ne tür bir tasarımın ne zaman tercih edileceği hakkında yazılmış tüm kitaplar var, bu yüzden burada herhangi bir kural listelemeyeceğim, bu bölümdeki alan yeterli olmayacaktır. Bununla birlikte, bir sınıfla modellemek istediğiniz bir soyutlama için gerçek bir dünya örneğiniz varsa, eminim buradaki topluluk tasarımı geliştirmenize yardımcı olacaktır.

Diğer noktalarınızı ele almak için:

• "özellikleri hiçbir mantık ile özel destek alanları": Evet, haklısın, önemsiz alıcılar ve ayarlayıcılar için bu sadece gereksiz "gürültü". Bu tür bir "şişkinlik "ten kaçınmak için, C # özellik alma / ayarlama yöntemleri için bir kısayol sözdizimine sahiptir:

Yani yerine

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

yazmak

   public string Prop1 { get;set;}

veya

   public string Prop1 { get;private set;}

• "Birden fazla kurucu": bu kendi başına bir sorun değildir. İçinde örneğinizde gösterildiği gibi gereksiz kod çoğaltması olduğunda veya arama hiyerarşisi kıvrıldığında bir sorun oluşur. Bu, ortak parçaları ayrı bir işleve yeniden düzenleyerek ve yapıcı zincirini tek yönlü bir şekilde düzenleyerek kolayca çözülebilir.

• "Potansiyel olarak boş yapıcı nedeniyle hiçbir özelliğe değer atanmaz": C # 'da her veri tipinin açıkça tanımlanmış bir varsayılan değeri vardır. Özellikler bir kurucuda açıkça başlatılmazsa, bu varsayılan değeri atarlar. Bu kasıtlı olarak kullanılırsa , mükemmel olur - bu yüzden yazar ne yaptığını bilirse boş bir kurucu iyi olabilir.

• "Çok fazla özellik! (30 vakada)": evet, böyle bir sınıfı yeşil alan olarak tasarlamakta özgürseniz, 30 çok fazla, katılıyorum. Ancak, hepimizin bu lüksü yoktur (aşağıdaki yorumda eski bir sistem mi yazmadınız?). Bazen mevcut bir veritabanındaki veya dosyadaki kayıtları veya verileri bir üçüncü taraf API'sından sisteminize eşlemeniz gerekir. Yani bu durumlar için 30 özellik kişinin yaşaması gereken bir şey olabilir.

1. "Özelliklerde mantığı olmayan özel destek alanları gereksiz görünüyor ve sınıfı şişiriyor" diyerek zaten iyi bir argümanınız var.

2. Burada sorun birden fazla kurucu gibi görünmüyor.

3. Tüm mülkleri herkese açık olarak görmeye gelince ... Belki bu şekilde düşünün, eğer iş parçacıkları arasındaki tüm bu özelliklere erişimi senkronize etmek isteseydiniz zor zamanınız olurdu çünkü her yerde senkronizasyon kodu yazmanız gerekebilir Kullanılmış. Ancak, tüm özellikler getters / setters tarafından çevrilmişse, senkronizasyonu sınıfa kolayca oluşturabilirsiniz.

4. "Davranışı test etmek zor" derken argüman kendisi için konuşur. Testinizin boş olup olmadığını veya böyle bir şey olup olmadığını kontrol etmesi gerekebilir (mülkün kullanıldığı her bir yer). Gerçekten bilmiyorum çünkü testinizin / uygulamanızın neye benzediğini bilmiyorum.

5. Çok fazla özelliğe sahipsin, miras kullanmayı deneyebilirsin (özellikler yeterince benziyorsa) ve sonra jenerikleri kullanarak bir liste / dizi var mı? Daha sonra bilgilere erişmek ve tüm özellikleri etkileşime girme şeklinizi basitleştirmek için alıcılar / ayarlayıcılar yazabilirsiniz.

Söylediğin gibi Foo, bir iş nesnesi. Alan adınıza göre yöntemlerde bazı davranışları kapsüllemeli ve verileri mümkün olduğunca kapsüllenmiş olarak kalmalıdır.

Gösterdiğiniz örnekte, Foodaha çok bir DTO'ya benziyor ve tüm OOP ilkelerine karşı çıkıyor (bkz. Anemik Alan Modeli )!

Iyileştirmeler olarak ben tavsiye ederim:

• Bu sınıfı mümkün olduğunca değişmez yapın . Söylediğiniz gibi, bazı birim testleri yapmak istiyorsunuz. Bir birim test için zorunlu yeteneği determinizmdir ve çözer çünkü determinism değişmezlik ile elde edilebilir yan etkilerin sorun.
• Bu tanrı sınıfını , her biri sadece 1 şey yapan birden fazla sınıfa ayırın (bakınız SRP ). Birim gerçekten bir PITA'da 30 nitelik sınıfını test eder .
• Yalnızca 1 ana kurucuya ve ana kurucuyu çağıran diğerlerine sahip olarak kurucu artıklığını kaldırın .
• Gereksiz alıcıları kaldırın, tüm alıcıların gerçekten yararlı olduğundan şüpheliyim.
• İşletme sınıflarında iş mantığını geri getirin, işte orası ait!

Bu, şu ifadelerle potansiyel olarak yeniden düzenlenmiş bir sınıf olabilir:

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

İş nesnesi sınıfı tasarımın bu “tamamen halka açık” zihniyetine nasıl karşı çıkılır?

• "Müşteri sınıf (lar) ına" sadece DTO görevi "nden daha fazlasını yapan çeşitli yöntemler vardır. Bunlar birbirlerine aittir."
• "Bu bir 'DTO' olabilir ama iş kimliği vardır - Eşittir'i geçersiz kılmamız gerekir."
• "Bunları sıralamamız gerekiyor - IComparable'ı uygulamamız gerekiyor"
• "Bu özelliklerin birkaçını bir araya getiriyoruz. Her istemcinin bu kodu yazmak zorunda kalmaması için ToString'i geçersiz kılalım."
• "Bu sınıfa aynı şeyi yapan birden fazla istemcimiz var. Kodu KURUYORUZ."
• "Müşteri bu şeylerin bir koleksiyonunu manipüle ediyor. Özel bir koleksiyon sınıfı olması gerektiği açıktır ve önceki noktaların birçoğu bu özel koleksiyonu şu anda olduğundan daha işlevsel hale getirecektir."
• "Tüm sıkıcı, açıkta, dizi manipülasyonlarına bakın! İş ile ilgili yöntemlerde kodlama verimliliğimizi artıracak."
• "Bu yöntemleri birlikte sınıfa çekmek onları test edilebilir yapacaktır çünkü daha karmaşık müşteri sınıfıyla uğraşmak zorunda değiliz."

• "Şimdi bu yeniden düzenlenmiş yöntemleri birim test edebiliriz. Çünkü x, y, z nedenlerinden dolayı müşteri test edilemez.

• Yukarıdaki argümanlardan herhangi biri, toplu olarak yapılabilir:

  • İşlevsellik yeniden kullanılabilir hale gelir.
  • Bu kuru
  • Müşterilerden ayrıldı.
  • sınıfa karşı kodlama daha hızlı ve daha az hataya açıktır.
• "İyi yapılmış bir sınıf, durumu gizler ve işlevselliği ortaya koyar. Bu, OO sınıflarını tasarlamak için başlangıç ​​önerisidir."
• "Nihai sonuç, iş alanını, farklı varlıkları ve açık etkileşimlerini ifade etmekten çok daha iyi bir iş çıkarıyor."
• "Bu 'genel gider' işlevselliği (yani açık işlevsel gereksinimler değil, yapılması gerekiyor) açıkça öne çıkıyor ve Tek Sorumluluk İlkesine bağlı kalıyor.