“Miras yerine kompozisyonu tercih et” - İmza değişikliklerine karşı savunmanın tek nedeni mi?

Bu sayfa , miras üzerinde kompozisyonu aşağıdaki argümanla savunuyor (kelimelerimde yeniden ifade etti):

Üst sınıf yönteminin imzasındaki bir değişiklik (alt sınıfta geçersiz kılınmamış olan), Devralma kullandığımızda birçok yerde ek değişikliklere neden olur. Ancak, Kompozisyon'u kullandığımızda, gerekli ek değişiklik yalnızca tek bir yerde bulunur: Alt sınıf.

Miras yerine kompozisyonu tercih etmenin tek nedeni bu mu? Çünkü bu durumda, alt sınıf uygulamayı değiştirmese bile (yani, alt sınıfa kukla geçersiz kılmalar koyarak) üst sınıfın tüm yöntemlerini geçersiz kılan bir kodlama stili uygulanarak bu sorun kolayca hafifletilebilir. Burada bir şey mi eksik?

Ben benzetmeleri seviyorum, işte bir tane: Hiç dahili VCR oynatıcısı olan TV'lerden birini gördünüz mü? VCR ve DVD oynatıcı olana ne dersiniz? Veya Blu-ray, DVD ve VCR'ye sahip olanlardan. Oh ve şimdi herkes akış yapıyor, bu yüzden yeni bir TV seti tasarlamamız gerekiyor ...

Büyük olasılıkla, bir TV setiniz varsa, yukarıdaki gibi bir setiniz yoktur. Muhtemelen bunların çoğu hiç var olmamıştır. Büyük olasılıkla çok sayıda girişe sahip bir monitörünüz veya setiniz vardır, böylece her yeni tip giriş cihazı olduğunda yeni bir sete ihtiyacınız yoktur.

Kalıtım, VCR yerleşik TV'ye benzer. Birlikte kullanmak istediğiniz 3 farklı türde davranışınız varsa ve her birinin uygulama için 2 seçeneği varsa, bunları temsil etmek için 8 farklı sınıfa ihtiyacınız vardır. Daha fazla seçenek ekledikçe sayılar patlar. Bunun yerine kompozisyon kullanırsanız, bu kombinatoryal problemden kaçınırsınız ve tasarım daha genişletilebilir olma eğilimindedir.

Hayır öyle değil. Miras üzerinde benim deneyim kompozisyonunda bir grup olarak yazılım düşüncesinin bir sonucudur nesneler ile davranışları o konuşma birbirlerine / nesneleri sağlayan hizmetler birbirleri yerine göre sınıflar ve veri .

Bu şekilde, hizmet sağlayan bazı nesneleriniz olur. Sen (örneğin bir diğer davranışı etkinleştirmek için (gerçekten hemen hemen Lego gibi) yapı taşları olarak kullanabilirsiniz UserRegistrationService bir tarafından sağlanan hizmetleri kullanan EmailerService ve UserRepository ).

Bu yaklaşımla daha büyük sistemler kurarken çok az durumda doğal olarak kalıtım kullandım. Günün sonunda miras, dikkatli bir şekilde ve sadece uygun olduğunda kullanılması gereken çok güçlü bir araçtır.

"Miras yerine kompozisyonu tercih et" sadece iyi bir buluşsal yöntemdir

Bağlamı düşünmelisiniz, çünkü bu evrensel bir kural değildir. Kompozisyon yapabildiğinizde asla miras kullanma anlamına gelmeyin. Eğer durum buysa, kalıtımı yasaklayarak düzeltirdiniz.

Umarım bu nokta bu yazı boyunca açıklığa kavuşturulur.

Kompozisyonun değerlerini tek başına savunmaya çalışmayacağım. Hangi konu dışı düşünün. Bunun yerine, geliştiricinin kompozisyonu daha iyi kullanacak miras olarak değerlendirebileceği bazı durumlar hakkında konuşacağım. Bu notta, mirasın kendi teması var, ki bu da konu dışı.

Araç örneği

Anlatım amacıyla, aptalca şeylere çalışan geliştiriciler hakkında yazıyorum

Bazı cepten kursları kullandığını bize klasik örneklerinden bir varyantı için gidelim ... Bir var Vehicle, sınıf o zaman türetmek Car, Airplane, Balloonve Ship.

Not : Bu örneği topraklamanız gerekiyorsa, bunların bir video oyunundaki tür nesneler olduğunu varsayalım.

O zaman Carve Airplanebazı ortak kodları olabilir, çünkü her ikisi de karada tekerlek üzerinde yuvarlanabilir. Geliştiriciler bunun için miras zincirinde bir ara sınıf oluşturmayı düşünebilirler. Yine de, Airplaneve arasında bazı paylaşılan kodlar da vardır Balloon. Bunun için miras zincirinde başka bir aracı sınıf oluşturmayı düşünebilirler.

Böylece, geliştirici çoklu miras arar. Geliştiricilerin birden fazla miras aradığı noktada, tasarım zaten yanlış gitti.

Bu davranışı arayüzler ve kompozisyon olarak modellemek daha iyidir, bu nedenle çoklu sınıf mirasına girmek zorunda kalmadan tekrar kullanabiliriz. Örneğin, geliştiriciler FlyingVehiculesınıfı oluşturun. Bunun Airplanebir FlyingVehicule(sınıf mirası) olduğunu söyleyebilirler, ancak bunun yerine Airplanebir Flyingbileşeni (kompozisyonu) ve Airplanebir IFlyingVehicule(arayüz mirası) olduğunu söyleyebiliriz .

Gerekirse, arayüzleri kullanarak çoklu kalıtım (arayüzlerin) olabilir. Ayrıca, belirli bir uygulamaya bağlanmıyorsunuz. Kodunuzun yeniden kullanılabilirliği ve test edilebilirliğinin artırılması.

Kalıtımın polimorfizm için bir araç olduğunu unutmayın. Ek olarak, polimorfizm yeniden kullanılabilirlik için bir araçtır. Kompozisyon kullanarak kodunuzun tekrar kullanılabilirliğini artırabilirseniz, bunu yapın. Kompozisyonun daha iyi tekrar kullanılabilirlik sağlayıp sağlamadığından emin değilseniz, "Kompozisyonu kalıtım yerine tercih et" iyi bir buluşsal yöntemdir.

Bütün bunlar bahsetmeden Amphibious.

Aslında, yerden çıkan şeylere ihtiyacımız olmayabilir. Stephen Hurn'un “Miras Üzerine Kompozisyonu İyileştirme” bölüm 1 ve bölüm 2 makalelerinde daha anlamlı bir örneği var .

Değiştirilebilirlik ve Kapsülleme

Miras mı Ayoksa beste Bmi olmalı ?

Bunun Abir uzmanlığı Liskov ikame ilkesiniB yerine getirecekse , kalıtım uygulanabilir, hatta arzu edilir. Geçerli bir ikame olmadığı durumlar varsa, miras kullanmamalıyız.AB

Türetilmiş sınıfı savunmak için bir tür savunmacı programlama biçimi olarak kompozisyonla ilgilenebiliriz . Özellikle, Bbaşka farklı amaçlar için kullanmaya başladıktan sonra , bu amaçlar için daha uygun olması için değiştirilmesi veya uzatılması yönünde bir baskı olabilir. BGeçersiz bir duruma yol açabilecek yöntemleri ortaya çıkarabilecek risk varsa A, miras yerine kompozisyon kullanmalıyız. Her ikisinin de yazarı olsak Bve Aendişelenmemiz gereken bir şey daha az olsa bile , kompozisyon yeniden kullanılabilirliği kolaylaştırır B.

Hatta varsa features iddia edebilir Bo Aihtiyacı yoktur (ve bu özellikler için geçersiz bir durumda neden olabilir eğer biz bilmiyoruz Amevcut uygulamadaki ya da gelecekte ya), bu kullanım bileşimine iyi bir fikirdir miras yerine.

Kompozisyon ayrıca anahtarlama uygulamalarına izin verme ve alaycılığı azaltma avantajlarına sahiptir.

Not : İkame geçerli olmasına rağmen kompozisyon kullanmak istediğimiz durumlar vardır. Bu ikame edilebilirliği arayüzler veya soyut sınıflar (ki bu başka bir konu olduğunda kullanılacak) kullanarak arşivler ve daha sonra gerçek uygulamanın bağımlılık enjeksiyonuyla kompozisyon kullanırız.

Son olarak, elbette, üst sınıfı savunmak için kompozisyon kullanmamız gerektiği argümanı vardır, çünkü miras ana sınıfın kapsüllenmesini bozar:

Miras, bir alt sınıfı ebeveyninin uygulamasının ayrıntılarına maruz bırakır, genellikle 'miras kapsüllemeyi keser' denir

- Tasarım Desenleri: Yeniden Kullanılabilir Nesneye Yönelik Yazılım Öğeleri, Dörtlü Çete

Bu kötü tasarlanmış bir ebeveyn sınıfı. Bu yüzden:

Miras için tasarım yapın veya yasaklayın.

- Etkili Java, Josh Bloch

Yo-Yo sorunu

Kompozisyonun yardımcı olduğu bir başka durum Yo-Yo problemidir . Bu Wikipedia'dan bir alıntı:

Yazılım geliştirmede yo-yo problemi, bir programcının kalıtım grafiği o kadar uzun ve karmaşık olan bir programı okuması ve anlaması gerektiğinde ortaya çıkan bir anti-modeldir ve programcı takip etmek için birçok farklı sınıf tanımı arasında dolaşmaya devam etmelidir. programın kontrol akışı.

Çözebilirsiniz, örneğin: Sınıfınız sınıftan Cmiras alınmaz B. Bunun yerine sınıfınızda Ctürden Abir nesne olabilir (veya olmayabilir) veya türünde bir nesne olabilir B. Bu şekilde, uygulama detaylarına Bkarşı değil, arayüzün (of) Asunduğu sözleşmeye karşı programlama yapacaksınız .

Sayaç örnekleri

Birçok çerçeve kompozisyon üzerinde kalıtımı desteklemektedir (tartıştığımız şeyin tersidir). Geliştirici bunu yapabilir, çünkü temel sınıflarına kompozisyonla birlikte uygulandığında istemci kodunun boyutunu artıracaktır. Bazen bunun nedeni dilin sınırlamalarıdır.

Örneğin, bir PHP ORM çerçevesi, nesnenin gerçek özelliklere sahipmiş gibi kod yazmaya izin vermek için sihirli yöntemler kullanan bir temel sınıf oluşturabilir. Bunun yerine, sihirli yöntemlerle işlenen kod veritabanına gidecek, istenen belirli alanı sorgulayacak (belki de gelecekteki istek için önbelleğe alacak) ve döndürecektir. Kompozisyon ile yapılması, istemcinin her alan için özellikler oluşturmasını veya sihirli yöntemler kodunun bir sürümünü yazmasını gerektirir.

Ek : ORM nesnelerinin genişletilmesine izin vermenin başka yolları da vardır. Dolayısıyla, bu davada kalıtımın gerekli olduğunu düşünmüyorum. O daha ucuz.

Başka bir örnek olarak, bir video oyunu motoru, 3B oluşturma ve olay işleme için hedef platforma bağlı olarak yerel kodu kullanan bir temel sınıf oluşturabilir. Bu kod karmaşık ve platforma özgüdür. Motorun geliştirici kullanıcısının bu kodla başa çıkması pahalı ve hataya yatkındır, aslında motoru kullanma nedeninin bir parçasıdır.

Ayrıca, 3B oluşturma parçası olmadan, bu kaç widget çerçevesi çalışır. Bu, işletim sistemi mesajlarını ele alma konusunda endişelenmenizi önler ... aslında, birçok dilde, yerel bir tür teklif olmadan bu kodu yazamazsınız. Dahası, eğer bunu yaparsanız, taşınabilirliğinizi sıkılaştırırdı. Bunun yerine, geliştiricinin uyumluluğu bozmaması koşuluyla kalıtımla (çok fazla); kodunuzu gelecekte destekleyecekleri yeni platformlara kolayca taşıyabileceksiniz.

Ayrıca, birçok kez yalnızca birkaç yöntemi geçersiz kılmak ve diğer her şeyi varsayılan uygulamalarla bırakmak istediğimizi düşünün. Kompozisyon kullansaydık, sadece sarılmış nesneye delege olsa bile, tüm bu yöntemleri yaratmamız gerekirdi.

Bu argümanla, kompozisyonun kalıtım için kalıtımdan daha kötü olabileceği bir nokta vardır (temel sınıf çok karmaşık olduğunda). Yine de, kalıtımın sürekliliğinin bileşiminkinden daha kötü olabileceğini (kalıtım ağacı çok karmaşık olduğunda), yo-yo probleminde bahsettiğim şey budur.

Sunulan örneklerde, geliştiriciler nadiren kalıtım yoluyla üretilen kodu diğer projelerde yeniden kullanmayı planlamaktadır. Bu, miras kullanımının kompozisyon yerine yeniden kullanılabilirliğinin azaltılmasını azaltır. Buna ek olarak, miras kullanarak çerçeve geliştiricileri kullanımı kolay ve keşfedilmesi kolay bir kod sağlayabilir.

Son düşünceler

Gördüğünüz gibi, kompozisyon her zaman değil, bazı durumlarda kalıtım üzerinde bazı avantajlara sahiptir. Kararı vermek için bağlamı ve ilgili farklı faktörleri (yeniden kullanılabilirlik, sürdürülebilirlik, test edilebilirlik vb.) Dikkate almak önemlidir. İlk noktaya dönelim: "Kompozisyonu kalıtım yerine tercih et" sadece iyi bir buluşsal yöntemdir.

Ayrıca açıkladığım durumların çoğunun bir dereceye kadar Özellikler veya Mixinler ile çözülebileceğini fark edebilirsiniz. Ne yazık ki, bunlar büyük dil listesinde ortak özellikler değildir ve genellikle bazı performans maliyetleriyle birlikte gelirler. Neyse ki, popüler kuzenleri Genişletme Yöntemleri ve Varsayılan Uygulamalar bazı durumları azaltır.

_{Arayüzlerin bazı avantajları hakkında neden konuştuğum son bir yazım var, neden C #'da UI, İş ve Veri erişimi arasında arayüzlere ihtiyacımız var . Ayrışmaya yardımcı olur ve yeniden kullanılabilirliği ve test edilebilirliği kolaylaştırır, ilgilenebilirsiniz.}

Normalde Kompozisyon-Devralmanın itici fikri, daha fazla tasarım esnekliği sağlamak ve bir değişikliği yaymak için değiştirmeniz gereken kod miktarını azaltmamaktır (şüpheli bulduğum).

Üzerinde örnek wikipedia onun yaklaşımının gücünün daha iyi bir örnek vermek:

Her bir "kompozisyon parçası" için bir temel arayüz tanımlayarak, yalnızca kalıtımla ulaşılması zor olabilecek bir çeşitlilikle çeşitli "birleşik nesne" oluşturabilirsiniz.

"Kompozisyonu kalıtım yerine tercih et" çizgisi doğru yönde bir dürtmeden başka bir şey değildir. Sizi kendi aptallığınızdan kurtaramaz ve aslında işleri daha da kötüleştirme şansı verir. Çünkü burada çok fazla güç var.

Bunun bile söylenmesinin ana nedeni programcıların tembel olmalarıdır. O kadar tembeldir ki daha az klavye yazımı anlamına gelen herhangi bir çözümü alacaklardır. Mirasın ana satış noktası budur. Bugün daha az yazıyorum ve yarın başka biri mahvoluyor. Ne yani, eve gitmek istiyorum.

Ertesi gün patron kompozisyon kullanmamda ısrar ediyor. Nedenini açıklamıyor ama üzerinde ısrar ediyor. Bu yüzden miras aldığım şeyin bir örneğini alıyorum, miras aldığımla aynı arayüzü açıyorum ve tüm çalışmaları miras aldığım şeye devrederek bu arayüzü uyguluyorum. Tamamen beyin ölü yazarak bir yeniden düzenleme aracıyla yapılabilirdi ve bana anlamsız geliyor ama patron bunu istedi, ben de yaptım.

Ertesi gün istediğim bu mu diye soruyorum. Patron ne diyor?

Bazılarının (çalışma zamanında) devralınan şeyi (durum modeline bakın) dinamik olarak değiştirebilmesi gerekmedikçe, bu çok büyük bir zaman kaybıdır. Patron bunu nasıl söyleyebilir ve miras üzerine kompozisyon lehine olabilir mi?

Buna ek olarak, yöntem imza değişikliklerinden dolayı kırılmayı önlemek için bir şey yapmamak, bileşimin en büyük avantajını tamamen kaçırır. Kalıtımdan farklı olarak farklı bir arayüz oluşturabilirsiniz . Bu seviyede nasıl kullanılacağına bir tane daha uygun. Bilirsin, soyutlama!

Kalıtımın bileşimi ve yetki devriyle (ve bazı dezavantajlarıyla) otomatik olarak değiştirilmesinin bazı küçük avantajları vardır, ancak bu işlem sırasında beyninizi kapalı tutmanın büyük bir fırsatı yoktur.

Dolaylı aktarım çok güçlüdür. Akıllıca kullanın.

İşte başka bir neden: birçok OO dilinde (burada C ++, C # veya Java gibi olanları düşünüyorum), bir nesne oluşturduktan sonra sınıfını değiştirmenin bir yolu yoktur.

Bir çalışan veritabanı oluşturduğumuzu varsayalım. Soyut bir temel Çalışan sınıfımız var ve belirli roller için yeni sınıflar türetmeye başlıyoruz - Mühendis, Güvenlik Görevlisi, Kamyon Sürücüsü vb. Her sınıfın bu rol için özel davranışı vardır. Herşey iyi.

Sonra bir gün bir Mühendis Mühendislik Müdürlüğüne terfi eder. Mevcut bir Mühendis'i yeniden sınıflandıramazsınız. Bunun yerine, bir Mühendislik Yöneticisi oluşturan bir işlev yazmanız, Mühendis'deki tüm verileri kopyalamanız, Mühendis'i veritabanından silmeniz ve ardından yeni Mühendislik Yöneticisi'ni eklemeniz gerekir. Ve olası her rol değişikliği için böyle bir işlev yazmalısınız.

Daha da kötüsü, bir Kamyon Sürücüsünün uzun süreli hastalık iznine gittiğini ve bir Güvenlik Görevlisinin Kamyon Sürüşü'nü doldurmak için yarı zamanlı yapmayı önerdiğini varsayalım. Şimdi onlar için yeni bir Güvenlik Görevlisi ve Kamyon Sürücüsü sınıfı icat etmelisiniz.

Somut bir Çalışan sınıfı oluşturmak ve iş rolü gibi özellikler ekleyebileceğiniz bir kapsayıcı olarak muamele etmek hayatı kolaylaştırır.

Kalıtım iki şey sağlar:

1) Kodun yeniden kullanımı: Kompozisyon ile kolayca yapılabilir. Ve aslında, kapsüllemeyi daha iyi koruduğu için kompozisyon yoluyla daha iyi elde edilir.

2) Polimorfizm: "Arabirimler" (tüm yöntemlerin saf sanal olduğu sınıflar) ile gerçekleştirilebilir.

Arabirim dışı kalıtım kullanmak için güçlü bir argüman, gerekli yöntem sayısının fazla olması ve alt sınıfınızın yalnızca küçük bir alt kümesini değiştirmek istediği zamandır. Bununla birlikte, "tek sorumluluk" ilkesine (eğer yapmanız gerekir) abone olursanız, genel olarak arayüzünüzün çok küçük ayak izleri olmalıdır, bu nedenle bu durumlar nadir olmalıdır.

Tüm üst sınıf yöntemlerinin geçersiz kılınmasını gerektiren kodlama stiline sahip olmak, zaten çok sayıda doğrudan geçiş yöntemini yazmaktan kaçınmıyor, bu yüzden neden kodu kompozisyon aracılığıyla yeniden kullanmıyorsunuz ve kapsülleme avantajından faydalanmıyorsunuz? Ayrıca, süper sınıf başka bir yöntem eklenerek genişletilecekse, kodlama stili bu yöntemi tüm alt sınıflara eklemeyi gerektirir (ve o zaman "arayüz ayırma" yı ihlal etme şansımız vardır ). Kalıtım birden çok düzeyde sahip olduğunuzda, bu sorun hızla büyür.

Son olarak, birçok dilde birim kompozisyonu "kompozisyon" temelli nesneler, üye nesneyi bir sahte / test / kukla nesne ile değiştirerek "miras" temelli objeleri birim test etmekten çok daha kolaydır.

Miras yerine kompozisyonu tercih etmenin tek nedeni bu mu?

Hayır!

Kompozisyonun miras yerine tercih edilmesinin birçok nedeni vardır. Tek bir doğru cevap yok. Ama karışıma kalıtım üzerinde kompozisyonu tercih etmek için başka bir neden atacağım:

Kompozisyonun miras üzerine tercih edilmesi, kodunuzun okunabilirliğini artırır , bu da birden fazla kişiyle büyük bir proje üzerinde çalışırken çok önemlidir.

İşte şöyle düşünüyorum: Başka birinin kodunu okurken, bir sınıfı genişlettiklerini görürsem , süper sınıfta hangi davranışın değiştiğini soracağım ?

Ve sonra kodlarını gözden geçireceğim, geçersiz kılınan bir işlev arıyorum. Eğer hiç görmezsem, bunu mirasın kötüye kullanılması olarak sınıflandırırım. Sadece beni (ve takımdaki diğer her kişiyi) kodlarını okuduktan 5 dakika sonra kurtarmak için kompozisyon kullanmalılardı!

Somut bir örnek: Java'da JFramesınıf bir pencereyi temsil eder. Bir pencere oluşturmak için, bir örnek oluşturur JFrameve daha sonra bu örneğe bir şeyler eklemek ve onu göstermek için işlevleri çağırırsınız.

Birçok öğretici (resmi olanlar bile) JFramesınıfınızın örneklerini örnek olarak ele alabilmeniz için genişletmenizi önerir JFrame. Ama imho (ve başkalarının görüşü), bunun içine girmek için oldukça kötü bir alışkanlıktır! Bunun yerine, yalnızca bir örnek oluşturmanız JFrameve bu örnekte işlev çağırmanız gerekir. JFrameÜst sınıfın varsayılan davranışlarından hiçbirini değiştirmediğiniz için bu örnekte genişletmeye gerek yoktur .

Öte yandan, özel boyama yapmanın bir yolu JPanelsınıfı genişletmek ve paintComponent()işlevi geçersiz kılmaktır . Bu kalıtımın güzel bir kullanımıdır. Kodunuza bakıyorum JPanelve paintComponent()işlevi genişletip geçersiz kıldığınızı görüyorsanız, tam olarak hangi davranışı değiştirdiğinizi bileceğim.

Sadece kendiniz kod yazıyorsanız, kompozisyon kullanmak kadar kalıtım kullanmak da kolay olabilir. Ancak grup ortamında olduğunuzu ve diğer kişilerin kodunuzu okuyacağını düşünün. Kompozisyonun miras yerine tercih edilmesi kodunuzun okunmasını kolaylaştırır.