Yalnızca yapıcı alt sınıflar: Bu bir kalıp karşıtı mı?

Bir iş arkadaşınızla bir tartışma yapıyordum ve alt sınıflamanın amacı hakkında çelişkili sezgiler yaşadık. Sezgim, eğer bir alt sınıfın birincil işlevi, üst öğesinin sınırlı bir değer değer aralığını ifade etmesiyse, o zaman muhtemelen bir alt sınıf olmamalıdır. Ters sezgi için savundu: alt sınıflamanın bir nesnenin daha "spesifik" olduğunu gösterir ve bu nedenle bir alt sınıf ilişkisi daha uygundur.

Sezgilerimi daha somut bir şekilde ifade etmek gerekirse, bir üst sınıfı genişleten bir alt sınıfa sahipsem ancak alt sınıfı geçersiz kılan tek kodun bir kurucu olduğunu düşünüyorum (evet, kurucuların genellikle "geçersiz kılma" etmediğini, o zaman benimle) gerçekte ihtiyaç duyulan şey yardımcı bir yöntemdi.

Örneğin, bu biraz gerçek hayat sınıfını düşünün:

public class DataHelperBuilder
{
    public string DatabaseEngine { get; set; }
    public string ConnectionString { get; set; }

    public DataHelperBuilder(string databaseEngine, string connectionString)
    {
        DatabaseEngine = databaseEngine;
        ConnectionString = connectionString;
    }

    // Other optional "DataHelper" configuration settings omitted

    public DataHelper CreateDataHelper()
    {
        Type dataHelperType = DatabaseEngineTypeHelper.GetType(DatabaseEngine);
        DataHelper dh = (DataHelper)Activator.CreateInstance(dataHelperType);
        dh.SetConnectionString(ConnectionString);

        // Omitted some code that applies decorators to the returned object
        // based on omitted configuration settings

        return dh;
    }
}

Onun iddiası şunun gibi bir alt sınıfa sahip olmanın tamamen uygun olacağını söyledi:

public class SystemDataHelperBuilder
{
    public SystemDataHelperBuilder()
        : base(Configuration.GetSystemDatabaseEngine(),
               Configuration.GetSystemConnectionString())
    {
    }
 }

Öyleyse, soru:

1. Tasarım kalıplarından bahseden insanlar arasında bu sezgilerden hangisi doğrudur? Alt sınıflama yukarıda açıklandığı gibi bir anti-patern midir?
2. Bir anti-patern ise, adı nedir?

Kolayca googleable bir cevap olduğu ortaya çıkarsa özür dilerim; google’da yaptığım aramalar çoğunlukla aradıklarım değil teleskop kurucu anti-patern hakkında bilgi verdi.

Tek yapmak istediğiniz, belirli argümanlarla X sınıfı oluşturmaksa, alt sınıflama bu amacı ifade etmenin tuhaf bir yoludur, çünkü sınıfların ve mirasın size sunduğu özelliklerin hiçbirini kullanmıyorsunuzdur. Gerçekten bir anti-patern değil, sadece garip ve biraz anlamsız (bunun için başka nedenleriniz yoksa). Bu amacı dile getirmenin daha doğal bir yolu, "yardımcı yönteminiz" için süslü bir isim olan bir Fabrika Yöntemi olacaktır .

Genel sezgiyle ilgili olarak, hem "daha spesifik" hem de "sınırlı bir aralık", alt sınıflar hakkında düşünmek için potansiyel olarak zararlı düşünme yollarıdır, çünkü her ikisi de Kare'yi Dikdörtgen'in bir alt sınıfını yapmanın iyi bir fikir olduğunu ima eder. LSP gibi resmi bir şeye güvenmeden, daha iyi bir sezginin, bir alt sınıfın ya temel arayüzün bir uygulamasını sağladığını ya da yeni işlevsellik eklemek için arayüzü genişlettiğini söyleyebilirim .

Bu sezgilerden hangisi doğrudur?

İş arkadaşınız doğru (standart tip sistemler varsayarsak).

Bir düşünün, sınıflar olası yasal değerleri temsil eder. Sınıfın Abir bayt alanı varsa F, bunun A256 yasal değere sahip olduğunu düşünmeye meyilli olabilirsiniz , ancak bu sezgi yanlış. A"her zaman değerlerin her geçirgenliğini" ile "kısıtlayan alan F" 0-255 olmalıdır ".

Başka bir bayt alanına Asahip Bolanı genişletirseniz FF, bu kısıtlama ekliyor . " FBayt olan değer" yerine " Fbayt FFolan ve aynı zamanda bayt olan" değerine de sahipsiniz . Eski kuralları koruduğunuzdan, bassetype için çalışan her şey hala alt türünüz için çalışır. Ancak kurallar eklediğiniz için, "her şey olabilir" den uzağa uzmanlaşıyorsunuz.

Ya da başka bir şekilde düşünmenin, varsayalım A: alt tipleri bir grup vardı B, Cve D. Bir tür değişkeni Abu alt türlerden herhangi biri olabilir, ancak bir tür değişkeni Bdaha belirgindir. (Çoğu tip sistemde) a Cveya a olamaz D.

Bu bir anti-kalıp mı?

Enh? Özel nesnelere sahip olmak kullanışlıdır ve yasalara açıkça zarar vermez. Alt sonucu kullanarak bu sonucun elde edilmesi belki biraz sorgulanabilir, ancak elinizde bulunan araçlara bağlıdır. Daha iyi araçlarla bile, bu uygulama basit, anlaşılır ve sağlamdır.

Bunu bir anti-patern olarak düşünmemeliyim çünkü hiçbir durumda açıkça yanlış ve kötü değil.

Hayır, bu bir anti-patern değil. Bunun için birkaç pratik kullanım durumu düşünebilirim:

1. Derleme zamanı kullanmak istiyorsanız, nesne koleksiyonlarının yalnızca belirli bir alt sınıfa uygun olduğundan emin olmak için kontrol edin. Örneğin, sisteminizde varsa MySQLDaove SqliteDaobazı nedenlerden dolayı, bir koleksiyonun yalnızca bir kaynaktan veri içerdiğinden emin olmak istiyorsanız, açıkladığınız gibi alt sınıflar kullanıyorsanız, derleyicinin bu özel doğruluğu doğrulamasını sağlayabilirsiniz. Diğer yandan, veri kaynağını bir alan olarak saklarsanız, bu bir çalışma zamanı kontrolü olur.
2. Benim şu anki uygulama arasındaki tek ilişki için bir birine sahiptir AlgorithmConfiguration+ ProductClassve AlgorithmInstance. Yapılandırmak Diğer bir deyişle, FooAlgorithmiçin ProductClassözellikler dosyasında, sadece bir tane alabilirsiniz FooAlgorithmo ürün sınıfı için. Verilen için iki FooAlgorithms elde etmenin tek yolu ProductClassbir alt sınıf oluşturmaktır FooBarAlgorithm. Bu tamam, çünkü özellikler dosyasının kullanımını kolaylaştırır (özellikler dosyasındaki bir bölümde birçok farklı yapılandırma için sözdizimine gerek yoktur) ve verilen bir ürün sınıfı için birden fazla örnek olması çok nadirdir.
3. @ Telastyn'ın cevabı başka iyi bir örnek veriyor.

Alt satır: Bunu yapmanın bir zararı yok. Bir Anti-pattern şöyle tanımlanır:

Bir anti-patern (veya antipattern), genellikle etkisiz olan ve oldukça fazla üretkenlik riski taşıyan tekrarlayan bir soruna ortak bir cevaptır .

Burada son derece üretken olma riski yoktur, bu nedenle bir anti-patern değildir.

Şey bir desen veya bir antipattern neyi dil ve çevre sizin yazmakta olduğunuz önemli ölçüde bağlıdır edin. Örneğin, fordöngüler bir desen olan montaj, C ve benzeri dillerde ve lisp bir antipattern.

Size uzun zaman önce yazdığım bazı kodların hikayesini anlatayım ...

LPC adlı bir dildeydi ve oyunda büyü yapmak için bir çerçeve oluşturdu. Bazı kontrolleri ele alan bir savaş büyücülerinin alt sınıfına sahip bir büyü süper sınıfına ve sonra tek hedef doğrudan hasar büyülerine yönelik bir alt sınıfa sahiptiniz, daha sonra bireysel büyülere sınıflanan - sihirli füze, yıldırım cıvatası ve benzeri.

LPC'nin çalışma şeklinin doğası, Singleton olan bir ana nesneye sahip olmanızdı. gitmeden önce 'eww Singleton' - öyleydi ve hiç "eww" değildi. Biri büyülerin kopyasını çıkarmamış, daha çok büyülerdeki (etkili) statik yöntemleri başlatmış. Sihirli füzenin kodu şöyle gözüküyordu:

inherit "spells/direct";

void init() {
  ::init();
  damage = 10;
  cost = 3;
  delay = 1.0;
  caster_message = "You cast a magic missile at ${target}";
  target_message = "You are hit with a magic missile cast by ${caster}";
}

Ve bunu görüyor musun? Bir kurucu sadece sınıf. Üst soyut sınıfında bulunan bazı değerleri belirledi (hayır, belirleyici kullanmamalı - değişmez) ve öyleydi. İşe yaradı sağ . Kodlaması kolay, genişletilmesi ve anlaşılması kolaydı.

Bu tür bir kalıp, soyut bir sınıfı genişleten ve kendi başına bir kaç değer ayarlayan bir alt sınıfın olduğu diğer durumlara dönüşür, ancak tüm işlevsellik miras aldığı soyut sınıftadır. Buna bir örnek olarak Java'da StringBuilder'a göz atın - yalnızca oldukça kurucu değil, ancak yöntemlerin kendisinde çok fazla mantık bulmaya zorlandım (her şey AbstractStringBuilder'da).

Bu kötü bir şey değildir ve kesinlikle bir anti-kalıp değildir (ve bazı dillerde bir kalıp olabilir).

Düşünebildiğim bu alt sınıfların en yaygın kullanımı istisna hiyerarşileridir, ancak bu, dil yapıcıları devraldığı sürece, sınıfta genellikle hiçbir şey tanımlayamayacağımız dejenere bir durumdur. Kalıtımın bunun ReadErrorözel bir durum olduğunu ifade etmek için kullanıyoruz IOError, ancak ReadErrorhiçbir yöntemi geçersiz kılmanıza gerek yok IOError.

Bunu yapıyoruz, çünkü istisnalar türlerini kontrol ederek yakalanıyor. Bu nedenle, türdeki uzmanlığı kodlamak zorundayız ki birileri isterse ReadErrorhepsini yakalamadan yakalayabilsin IOError.

Normalde, bir şeyleri kontrol etmek korkunç derecede kötü bir formdur ve bundan kaçınmaya çalışırız. Bundan kaçınmayı başarırsak, o zaman tip sistemindeki uzmanlıkları ifade etmek için gerekli bir gerek yoktur.

Yine de, örneğin, türün adı nesnenin kayıtlı dizgisi biçiminde göründüğünde yine de yararlı olabilir: bu dildir ve muhtemelen çerçeveye özgüdür. Sen prensipte biz bu durumda sınıfın bir yöntemi çağrısı ile bu tür sistemde türünün adını yerini alabilecek ediyorum daha sadece yapıcı daha geçersiz SystemDataHelperBuilder, biz de geçersiz olur loggingname(). Eğer sisteminizde böyle bir giriş varsa, sınıfınız kelimenin tam anlamıyla yapıcıyı geçersiz kılsa da, "ahlaki olarak" da sınıf adını geçersiz kıldığını ve pratik amaçlar için yalnızca kurucu alt sınıfı olmadığını hayal edersiniz. Arzu edilen farklı davranışlar var, '

Bu nedenle, kodunun başka yerde bir şekilde kontrol ettiği, örneğin SystemDataHelperBuilderbir şubeyle (türüne göre dalları yakalamak istisna gibi) veya belki de sonuçlanacak genel bir kod olduğu için kodunu iyi bir fikir olabilir ismi SystemDataHelperBuilderyararlı bir şekilde kullanmak (sadece kayıt olsa bile).

Bununla birlikte, özel durumlar için türlerin kullanılması bazı karışıklıklara yol açmaktadır, çünkü eğer herhangi bir şekilde farklı davranırlarsa ImmutableRectangle(1,1)ve sonunda birileri neden ve belki de istememesini merak eder. İstisna hiyerarşilerinden farklı olarak, bir dikdörtgenin kare olup olmadığını kontrol ederek birlikte olup olmadığını kontrol edin . Örneğinizde, aynı argümanlarla yaratılan a ile a arasında bir fark vardır ve bu problemlere neden olabilir. Bu nedenle, "doğru" argümanlarla oluşturulan bir nesneyi döndürme işlevi bana normalde yapılacak doğru şeyi gösterir: alt sınıf "aynı" şeyin iki farklı temsiline yol açar ve yalnızca siz bir şeyi yapıyorsanız yardımcı olur normalde yapmamaya çalışacağım.ImmutableSquare(1)height == widthinstanceofSystemDataHelperBuilderDataHelperBuilder

Not ben ediyorum değil ben bir programcı hiç düşünmediği tüm iyi ve kötü fikirlerin bir kategori sağlamaktadır mümkün olduğuna inanmıyorum, çünkü tasarım desenleri ve anti-desen açısından konuşurken. Bu nedenle, her fikir bir kalıp ya da kalıp karşıtı değildir, sadece biri farklı bağlamlarda tekrar tekrar meydana geldiğini tespit ettiğinde ve isimlendirdiğinde ;-) bu tür bir alt sınıflandırma için özel bir isim bilmiyorum.

Bir alt sınıf ilişkisinin en katı Nesne Yönelimli tanımı “is-a” olarak bilinir. Bir kare ve dikdörtgenin geleneksel örneğini kullanarak, bir kare «is-a» bir dikdörtgendir.

Bununla, bir "is-a" nın kodunuz için anlamlı bir ilişki olduğunu düşündüğünüz herhangi bir durum için alt sınıflamayı kullanmalısınız.

Özel bir alt sınıf durumunuzda, bir kurucudan başka bir şey olmadan, onu “bir” is perspektifinden analiz etmelisiniz. Bir SystemDataHelperBuilder «'in-a» DataHelperBuilder olduğu açıktır, bu nedenle ilk geçiş geçerli bir kullanım olduğunu öne sürer.

Cevaplamanız gereken soru, diğer kodlardan herhangi birinin bu «bir-a» ilişkisinden yararlanıp yararlanmadığıdır. Başka bir kod, SystemDataHelperBuilders'ı, genel DataHelperBuilders popülasyonundan ayırt etmeye çalışıyor mu? Eğer öyleyse, ilişki oldukça makul ve alt sınıfı korumalısınız.

Bununla birlikte, eğer başka bir kod bunu yapmazsa, sahip olduğunuz bir "is-a" ilişkisi olabilecek ya da bir fabrika ile uygulanabilecek bir ilişkidir. Bu durumda, her iki yönde de gidebilirsiniz, ancak “is-a” ilişkisi yerine bir Fabrika öneririm. Başka bir kişi tarafından yazılan Nesne Yönelimli kodu analiz ederken, sınıf hiyerarşisi önemli bir bilgi kaynağıdır. Kodu anlamalarını sağlayacak «is-a» ilişkilerini sağlar. Buna göre, bu davranışı bir alt sınıfa koymak, "birisinin üst sınıfın yöntemlerini araştırıp kazanamayacağı bir şey" den "davranışını" herkesin koda girmeden önce bakacakları bir şeye "terfi ettirir. Guido van Rossum'dan "kod, yazıldığından daha sık okunur" kodunuzu yaklaşan geliştiriciler için okunabilirliği azaltmak bu yüzden ödemek için katı bir fiyattır. Bir fabrika kullanabilirsem, ödememeyi seçerdim.

Alt türünün bir örneğini her zaman alt türün bir örneğiyle değiştirebildiğiniz ve her şeyin hala doğru şekilde çalışabildiğiniz sürece, alt tür hiçbir zaman "yanlış" değildir. Bu, alt sınıf, süper tipin verdiği garantilerin hiçbirini zayıflatmaya çalışmadığı sürece kontrol eder. Daha güçlü (daha spesifik) garantiler verebilir, bu nedenle iş arkadaşınızın sezgisi doğrudur.

Buna bakıldığında, yaptığınız alt sınıf muhtemelen yanlış değildir (ne yaptıklarını tam olarak bilmediğim için, kesin olarak söyleyemem.) Kırılgan temel sınıf sorununa karşı temkinli olmalısınız ve ayrıca bir interfaceavantajın size fayda sağlayıp sağlayamayacağını düşünün, ancak bu tüm miras kullanımları için geçerlidir.

Bence bu soruyu cevaplamanın anahtarı bu konuya, özel kullanım senaryosuna bakmak.

Kalıtım, bağlantı dizesi gibi veritabanı yapılandırma seçeneklerini zorlamak için kullanılır.

Bu bir anti örüntüdür, çünkü sınıf Tek Sorumluluk Sorumlusu ihlal ediyor - Kendisini o yapılandırmanın belirli bir kaynağı ile yapılandırıyor ve "Bir şey yapmak ve iyi yapmak" şeklinde değil. Bir sınıfın yapılandırması, sınıfın içine girmemelidir. Veritabanı bağlantı dizgilerini ayarlamak için, çoğu zaman uygulamanın başlatıldığı sırada gerçekleşen bir olay sırasında uygulama düzeyinde gerçekleştiğini gördüm.

Yapıcıyı yalnızca farklı kavramları ifade etmek için düzenli olarak alt sınıflar kullanıyorum.

Örneğin, aşağıdaki sınıfı göz önünde bulundurun:

public class Outputter
{
    private readonly IOutputMethod outputMethod;
    private readonly IDataMassager dataMassager;

    public Outputter(IOutputMethod outputMethod, IDataMassager dataMassager)
    {
        this.outputMethod = outputMethod;
        this.dataMassager = dataMassager;
    }

    public MassageDataAndOutput(string data)
    {
        this.outputMethod.Output(this.dataMassager.Massage(data));
    }
}

Daha sonra bir alt sınıf oluşturabiliriz:

public class CapitalizeAndPrintOutputter : Outputter
{
    public CapitalizeAndPrintOutputter()
        : base(new PrintOutputMethod(), new Capitalizer())
    {
    }
}

Daha sonra, CapitalizeAndPrintOutputter'ı kodunuzun herhangi bir yerinde kullanabilir ve tam olarak ne tür bir çıktı olduğunu bilirsiniz. Ayrıca, bu desen aslında bu sınıfı oluşturmak için bir DI konteynerini kullanmayı çok kolaylaştırıyor. DI kapsayıcısı PrintOutputMethod ve Capitalizer hakkında bir şey biliyorsa, sizin için otomatik olarak CapitalizeAndPrintOutputter uygulamasını da oluşturabilir.

Bu modeli kullanmak gerçekten oldukça esnek ve kullanışlıdır. Evet, olabilir aynı şeyi yapmak için fabrika yöntemleri kullanın ama sonra (C # en azından) Tür sisteminin gücünün bir kısmını kaybeder ve kesinlikle DI kapları kullanarak daha fazla hantal hale gelir.

İlk önce, kod yazılırken, alt sınıfın, başlangıçtaki iki alanın da her ikisi de müşteri koduyla ayarlanabildiği için, üst öğeden daha belirgin olmadığını unutmayın.

Alt sınıfın bir örneği yalnızca bir downcast kullanılarak ayırt edilebilir.

Şimdi, DatabaseEngineve ConnectionStringözelliklerinin alt sınıf tarafından yeniden uygulandığı, buna erişen bir tasarıma Configurationsahipseniz, o zaman alt sınıfa sahip olmak daha mantıklı olan bir kısıtlamaya sahip olursunuz.

"Anti-patern" in zevkime göre çok güçlü olduğunu söyleyerek; Burada gerçekten yanlış bir şey yok.

Verdiğiniz örnekte eşiniz haklı. İki veri yardımcı kurucuları stratejilerdir. Biri diğerinden daha spesifik, ancak ikisi de başlatıldıktan sonra değiştirilebilir.

Temel olarak, veri kurucu üreticisinin bir müşterisi systemdatahelperbuilder'ı almak olsaydı, hiçbir şey bozulmazdı. Diğer bir seçenek, systemdatahelperbuilder'ın datahelperbuilder sınıfının statik bir örneği olması olabilirdi.