Kalıtım için tasarım ekstra maliyete nasıl yol açabilir? [kapalı]

Bu yüzden bir csharpsealed class in miras almak istedim ve yandı. Kaynağa erişiminiz yoksa onu açmanın hiçbir yolu yoktur.

Sonra bana "neden sealedvar bile?" Diye düşündürdü . 4 ay önce. Bu konuda birçok şey okumasına rağmen anlayamadım:

• Jon Skeet'in dilekleri " sınıflar varsayılan olarak .NET'te mühürlendi. "
• Kompozisyon kalıtım yerine tercih edilmeli mi?
• "Tüm sınıfları mühürlememelisin (...)"
• Mühürlü bir sınıfla nasıl alay ediyorsun?

O zamandan beri hepsini sindirmeye çalıştım, ama bu benim için çok fazla. Sonunda dün tekrar denedim. Hepsini tekrar taradım, birkaç tane daha:

• Neden sınıf "soyut" veya "final / mühürlü" olmaktan başka bir şey olsun ki?
• 15 yıldan uzun bir süredir programlamada, zaten bağlantılı olan bir sorunun cevabından SOLID'i ilk kez duydum ve 4 ay önce hepsini okumadım

Sonunda, çok fazla düşünmeden sonra , orijinal başlığı yeni başlığa dayanarak ağır bir şekilde düzenlemeye karar verdim .

Eski bir soru çok geniş ve sübjektif idi. Temel olarak şunu soruyordu:

1. Eski başlıkta: Mühürlü kullanmak için iyi bir sebep
2. Vücutta: Mühürlü bir sınıf nasıl düzgün bir şekilde değiştirilir? Miras hakkını unuttun mu? Kompozisyon mu kullanıyorsunuz?

Ama şimdi, (ki dün yapmadığım) her şeyin mirasını önlediğini anlamak ve gerçekten miras üzerinde kompozisyon kullanabiliriz ve kullanmalıyız , ihtiyacım olanın pratik örnekler olduğunu fark ettim .sealed

Sanırım burada sorum, BayMindor'un bana bir sohbette bana önerdiği şey (ve aslında her zaman olmuştur) : Kalıtım için tasarım nasıl ekstra maliyete neden olabilir?

Bunu anlamak o kadar zor değil. sealedMicrosoft için özel olarak hayatlarını kolaylaştırmak, tonlarca tasarruf sağlamak ve itibarlarına yardımcı olmak için yaratılmıştır. Bir dil özelliği olduğu için herkes bunu da kullanabilir, ancak muhtemelen hiçbir zaman mühürlü kullanmanız gerekmeyecektir.

Çoğu insan bir sınıfı genişletememekten şikayet eder ve eğer yaparlarsa, herkesin doğru çalışmasını sağlamanın geliştiricilerin sorumluluğu olduğunu bildiğini söylerler. Bu doğru, ancak aynı insanların Windows tarihi hakkında hiçbir ipucu yok ve sorunlardan sealedbiri çözmeye çalışıyorum hariç .

Bir geliştiricinin .Net çekirdek sınıfını genişlettiğini varsayalım (çünkü mühürlü yoktu) ve mükemmel bir şekilde çalışmasını sağladık. Yay, geliştirici için. Geliştirici ürünü müşteriye teslim eder. Geliştiricinin uygulaması harika çalışıyor. Müşteri mutlu. Hayat güzel.

Microsoft artık bu belirli .Net çekirdek sınıfındaki hataları gidermeyi içeren yeni bir işletim sistemi yayınladı. Müşteri zamana ayak uydurmak istiyor ve yeni işletim sistemini kurmayı seçiyor. Birdenbire, müşterinin çok sevdiği uygulama artık çalışmıyor, çünkü .Net çekirdek sınıfında düzeltilen hataları hesaba katmadı.

Suçu kim alıyor?

Microsoft'un tarihine aşina olanlar, Microsoft'un yeni işletim sisteminin, Windows kütüphanelerini yanlış kullanan uygulama yazılımını değil, suçu alacağını biliyor. Bu nedenle, sorunu yaratan uygulama şirketi yerine sorunu düzeltmek Microsoft'ta görev alır. Windows kodunun şişirilmesinin nedenlerinden biri de budur. Okuduğum kadarıyla, Windows işletim sistemi kodu, belirli bir if-then ile belirli bir uygulamanın ve sürümün çalışıp çalışmadığını kontrol eder ve eğer öyleyse, programın çalışmasına izin vermek için bazı özel işlemler yapar. Bu, Microsoft'un başka bir şirketin yetersizliğini gidermek için harcadığı çok para.

Kullanmak sealedyukarıdaki senaryoyu tamamen ortadan kaldırmaz, ancak yardımcı olur.

sealedsınıf yazarının onu miras almak üzere tasarlamadığını belirtmek için kullanılır. Ne az, ne fazla.

Bir arabirimin uygun şekilde tasarlanması birçok programcı için yeterince zordur. Potansiyel olarak miras alınabilecek bir sınıfın uygun şekilde tasarlanması zorluk ve kod satırları ekler. Yazılan daha fazla kod satırı, daha fazla kodun korunması anlamına gelir. Artan bu zorluktan kaçınmak sealediçin, sınıfın asla miras alınmayı amaçlanmadığını gösterebilir ve bu bağlamda, bir sınıfı mühürlemek bir sorun için mükemmel geçerli bir çözümdür .

Sınıfın CustomBoeing787türetildiği vakayı düşünün Airliner. Bu, CustomBoeing787bazı korunan yöntemleri geçersiz kılar Airliner, ancak hepsinden değil. Geliştiricinin yeterli zamanı varsa ve buna değerse, geçersiz kılınan yöntemler çağrıldığında bile (örneğin nesnenin durumunu değiştiren korumalı ayarlayıcılar) bir bağlamda her şeyin beklendiği gibi çalışmasını sağlamak için sınıfı test edebilir. Aynı geliştiricinin (1) zamanı yoksa, (2) patronu / müşterisi için ek yüzlerce veya binlerce dolar harcamak istemiyorsa veya (3) sahip olmadığı ek kod yazmak istemiyorsa şu anda ihtiyacı var (YAGNI), o zaman yapabilir:

• ya bu kodu daha sonra potansiyel hataları açıklamak için bu projeyi sürdürecek olan programcıların endişesi göz önüne alındığında, vahşi doğada olduğu gibi bırakın,

• ya da sınıfı sealedgelecekteki programcılara bu sınıfın kalıtsal olarak tasarlanmadığını ve onu mühürlemenin ve bir ebeveyn olarak kullanmanın kendi sorumluluğunuzda olduğunu açıkça gösterecek şekilde işaretleyin .

Mümkün olduğunca çok veya mümkün olduğunca az sayıda sınıfı mühürlemek iyi bir fikir mi? Deneyimlerime göre, kesin bir cevap yok. Bazı geliştiriciler sealedçok fazla kullanma eğilimindedir ; diğerleri sınıfın nasıl miras alınacağı ve bunun neden olabileceği sorun umurumda değil. Böyle bir kullanım göz önüne alındığında, sorun programcıların girinti için iki veya dört boşluk kullanıp kullanmayacaklarını belirlemeye yarayan soruna benzer: doğru cevap yoktur.

Bir sınıf mühürlendiğinde, tam olarak neyle uğraştıklarını bilmek için bu türü kullanan kodlara izin verir.

Şimdi C # ' stringda sealed, ondan miras alamazsınız, ancak bir saniye için durumun böyle olmadığını varsayalım. Eğer yaptıysanız, birisi böyle bir sınıf yazabilir:

public class EvilString// : String
{
    public override string ToString()
    {
        throw new Exception("I'm mean");
    }
    public override bool Equals(object obj)
    {
        return false;
    }
    public override int GetHashCode()
    {
        return 0;
    }
}

Bu şimdi tasarımcıların doğru stringolduğunu bildikleri her türlü özelliği ihlal eden bir dize sınıfı olacaktır. EqualsYöntemin geçişli olacağını biliyorlardı , bu değil. Heck, bu eşittir yöntemi, simetrik bile değildir, çünkü bir dize ona eşit olabilir, ancak o dizeye eşit olmaz. Eminim ToStringyöntem stringnull olmayan değerler için bir istisna atmayacak varsayımı altında kod yazmış her türlü programcı vardır . Artık bu varsayımı ihlal edebileceksiniz.

Bunu yapabileceğimiz başka sınıflar ve ihlal edebileceğimiz diğer varsayımlar da var. İçin dil özelliğini kaldırırsanızsealeddil tasarımcıları artık tüm kütüphane kodlarında bu gibi şeyleri hesaba katmaya başlamalıdır. Kullanmak istedikleri türlerin genişletilmiş türlerinin "düzgün" olarak yazıldığından emin olmak için her türlü kontrolü gerçekleştirmeleri gerekir, bu da yapılması çok pahalı bir şey olabilir (hem geliştirme zamanında hem de çalışma zamanında). Bir sınıfı kapatarak bunun mümkün olmadığından ve kendi türlerinin uygulama ayrıntıları hakkında yaptıkları iddiaların, kasıtlı olarak genişletilmek üzere tasarlanan türler dışında ihlal edilemeyeceğinden emin olabilirler. Genişletilmek üzere tasarlanan bu türler için, dil kodunun onlarla nasıl başa çıktığı konusunda çok daha savunmacı olması gerektiğini göreceksiniz.

Mühürlü kullanmak için iyi bir neden var mı?

Enh? Sık değil. Ben iletmenin türüyle (veya başka bir sınırlama) olduğunda sadece mühürlü kullanılan olacaktır gerçekten gerçekten değişmez kalması gerekiyor ve ben güven varisleri sisteme ince, felaketli hata tanıtan olmadan bu şartı furfill için olamaz.

Mühürlü kullanmak için iyi bir neden olduğunu varsayalım ve her şey için varsayılan olarak kullanmalıyız, miras ile ne yapıyoruz?

Varsayılan olmayan şeyler için kalıtım kullanırız. Kompozisyon kalıtsallıktan yana olsa bile (ve öyle), bu kalıtımın atılması gerektiği anlamına gelmez. Bu, kalıtımın, tasarım ve kod sürdürülebilirliği ile ortaya koyduğu bazı temel problemlere sahip olduğu anlamına gelir ve kompozisyon (genel olarak) daha az problemle aynı şeyi yapar. Ve bu, kompozisyon tercih edilmesine rağmen, kalıtımın belirli problem alt kümeleri için iyi olduğu anlamına gelir.

Ben olmak istemem çok ortalama ama sadece şimdi KATI ve birim test duydum eğer, belki de rock ve aslında yazma kodu underneith kurtulmak gerekir. İşler net bir şekilde kesilmez ve nadiren "her zaman X yapar" veya "asla Y kullanmayın" ya da "Z en iyisidir" doğru yol olacaktır (sanki sorunuzun görüşlerine göre yönelirsiniz gibi). Kod yazarken, diğer herhangi bir ödünleşimde olduğu gibi,sealed iyi olabilecek vakaları ve kedere neden olduğu vakaları görebilirsiniz .

Her şeyden önce, Eric Lippert'in Microsoft'un neden sınıflarını mühürlediğine dair yazısını okumalısınız.

http://blogs.msdn.com/b/ericlippert/archive/2004/01/22/61803.aspx

İkinci olarak, kapalı anahtar kelime tam olarak ne yaptığını yapmak için var - kalıtımı önlemek. Devralmayı önlemek istediğiniz birçok durum vardır. Koleksiyonunuz olan bir sınıfı düşünün. Kodunuz belirli bir tarzda çalışan bu sınıfa bağlıysa, o sınıftaki yöntemlerden veya özelliklerden birini geçersiz kılan ve uygulamanızın başarısız olmasına neden olan birisinin olmasını istemezsiniz.

Üçüncüsü, mühürlü kullanılması, kalıtım üzerine kompozisyonu teşvik eder, bu da içine girmek için iyi bir alışkanlıktır. Kompozisyonun miras üzerinde kullanılması, Liskov'un ikame ilkesini kıramayacağınız ve Açık / Kapalı prensibini izlediğiniz anlamına gelir. sealedbu nedenle oo programlamanın en önemli beş ilkesinden ikisinde size yardımcı olan bir anahtar kelimedir. Bunun çok değerli bir özellik olduğunu söyleyebilirim.

Bu sorunun objektif bir cevabı olmadığını ve her şeyin sizin bakış açınıza bağlı olduğunu düşünüyorum.

Bir taraf, bazı insanlar her şeyin "açık" olmasını ister ve her şeyin doğru şekilde çalışmasını sağlama yükü, sınıfı genişleten kişidir. Bu yüzden sınıflar varsayılan olarak mirasa açıktır. Java yöntemlerinin neden varsayılan olarak sanal olduğunu.

Diğer tarafta, bazıları her şeyin varsayılan olarak kapatılmasını ve açmak için seçenekler sunmasını ister. Bu durumda, "açık" hale getirdiği her şeyin akla gelebilecek herhangi bir şekilde güvenli olduğundan emin olması gereken temel sınıfın yazarıdır. Bu nedenle C # 'da tüm yöntemler varsayılan olarak sanal değildir ve geçersiz kılmak için sanal olarak bildirilmesi gerekir. Aynı zamanda "açık" varsayılanları atlatmanın bir yolu olması gereken insanlar içindir. Sınıfı kapalı / final yapmak gibi, çünkü sınıftan türeyen birini kendi sınıfının tasarımında büyük bir sorun olarak görürler.

C # ile mühürlü sorun oldukça son olmasıdır. C # ticari geliştirme 7 yıl içinde, onu gördüğüm tek yer, ayarlanmış davranışı uygulamak için bir çerçeve sınıfı genişletmek için meşru bir neden olduğunu hissediyorum Microsoft .NET sınıflarında olduğunu ve sınıf mühürlendi, çünkü yapamadım .

Kullanılabilecek her türlü yolu düşünen ve hiçbirinin meşru olmadığına karar veren bir sınıf yazmak imkansızdır. Benzer şekilde, çerçeve güvenliği miras alınmayan sınıfa bağlıysa, bir güvenlik tasarım kusurunuz vardır.

Sonuç olarak, mühürlenmiş olanın yararlı bir amaca hizmet etmediği fikrine kesinlikle inanıyorum ve şimdiye kadar burada okuduğum hiçbir şey bu görüşü değiştirmedi.

Şimdiye kadar mühürlü haklı gösteren üç argüman olduğunu görebiliyorum.

1. Tartışma 1, insanlar sınıflardan miras aldıklarında ve daha sonra içselleri gerçekten anlamadan o sınıfın içlerine daha fazla erişime sahip olduklarında bir hata kaynağını ortadan kaldırmasıdır.

2. Argüman 2, bir microsoft sınıfını genişletir ve ardından microsoft bu sınıfta bir hata düzeltmesi uygular, ancak uzantınız bu hataya dayanırsa, kodunuz şimdi bozulur, microsoft suçu alır ve mühürlü

3. Tartışma 3, sınıfın geliştiricisi olarak, sınıf tasarımımın bir parçası olarak, onu genişletmenize izin verip vermememdir.

Bağımsız değişken 1, son programcı kodumu nasıl kullanacağınızı bilmediğinizin bir argümanı gibi görünüyor. Durum bu olabilir, ancak yine de nesneler arayüzüne erişmeme izin verirseniz, nesnenizi kullandığım ve nasıl kullanılacağını anlamadan ona çağrı yaptığım doğru olur ve bu şekilde bu kadar zarar verebilir. . Bu mühürlü ihtiyacın zayıf bir gerekçesi.

Arg 2 için olgusal tabanın nereden geldiğini anlıyorum. Özellikle microsoft, Windows XP'nin Windows NT ile karşılaştırıldığında genel kararlılığını geliştiren, ancak Windows XP piyasaya sürüldüğünde birçok uygulamanın kırıldığı kısa vadeli maliyetle, hatalı biçimlendirilmiş çağrıları tanımlamak için win32 api çağrılarına ek OS kontrolleri yaptığında. Microsoft, bu denetimlerin söylenmesi için 'kurallar' koyarak bunu çözdü, uygulama X bu kuralı ihlal ettiğinde yoksay, bilinen bir hata

Argüman 2 kötü bir argüman çünkü en iyi mühürlü bunun yanında bir fark yaratmıyor çünkü .NET kütüphanesinde bir hata varsa, bir iş bulmaktan başka seçeneğiniz yok ve microsoft fix ortaya çıktığında, büyük olasılıkla demek ki, etrafınızdaki kırık davranışa bağlı olan işiniz artık bozuldu İster miras kullanarak ister başka bir ek sarmalayıcı kodu kullanarak bu sorunu çözmüş olsanız da, kod sabitlendiğinde, etrafınızdaki çalışma bozulacaktır.

Argüman 3, kendisini haklı çıkaracak herhangi bir maddeye sahip olan tek argüman. Ama yine de zayıf. Sadece kod yeniden kullanımına karşı gider.

sealedYalnızca statik yöntemler içeren sınıflarda anahtar sözcük kullanıyorum .

Sorumdan da anlaşılacağı gibi, burada uzman değilim. Ama var olmak için hiçbir neden göremiyorum sealed.

Kod mimarlarının bir arayüz tasarlamasına yardımcı olmak için yapılmış gibi görünüyor. Vahşi doğada çıkacak bir sınıf yazmak istiyorsanız ve birçok insan ondan miras alacaksa, o sınıftaki herhangi bir şeyi değiştirmek onu çok fazla insan için kırabilir. Böylece onu mühürleyebiliriz ve kimse miras alamaz. "Sorun çözüldü".

Şey, "bir noktayı örtmek ve bir başkasını ortaya çıkarmak" gibi görünüyor. Ve bir problemi bile çözmüyor - sadece bir aracı yok ediyor : kalıtım. Herhangi bir araç olarak, birçok kullanımı vardır ve dengesiz bir sınıftan miras almak, aldığınız bir risktir. Bu riski alan herkes daha iyi bilmelidir.

Belki bir anahtar kelime olabilir stable, bu yüzden insanlar anahtar kelimeyi devralmanın daha güvenli olduğunu bilir.