Bu “mirasa karşı iyilik kompozisyonu” kavramı nereden geliyor?

Son birkaç ayda, "mirasa karşı iyilik kompozisyonu" mantığı hiçbir yerden fırlamış ve programlama topluluğu içinde neredeyse bir çeşit meme haline gelmiş gibi görünmektedir. Ve onu her gördüğümde biraz şaşırdım. Birinin dediği gibi "kırıcıların lehine matkaplar". Tecrübelerime göre, kompozisyon ve kalıtım, farklı kullanım durumlarına sahip iki farklı araç ve bunları birbirinin yerine geçiyormuş gibi ele alıyor ve biri doğası gereği diğerinden üstündü.

Ayrıca, kalıtımın neden kötü olduğu ve kompozisyonun iyi olduğu için gerçek bir açıklama görmüyorum , bu da beni daha da şüpheli kılıyor. Sadece inanca kabul edilmesi mi gerekiyor? Liskov ikame ve polimorfizminin iyi bilinen ve net faydaları vardır ve IMO, nesne yönelimli programlama kullanımının tüm noktasını oluşturur ve hiç kimse neden kompozisyon lehine atılmaları gerektiğini açıklamaz.

Bu kavramın nereden geldiğini ve arkasındaki mantığın ne olduğunu bilen var mı?

GoF'ten çok önce kompozisyon-miras miras tartışmaları duyduğumu düşünmeme rağmen, parmağımı belirli bir kaynağa koyamıyorum. Yine de Booch olmuş olabilir.

<Rant>

Ah, ancak birçok mantrada olduğu gibi, bu tipik çizgiler boyunca yozlaşmıştır:

1. Bu, özgün karmaşık tartışmanın bir hatırlatıcısı olarak catch-cümlesini oluşturan saygın bir kaynak tarafından ayrıntılı bir açıklama ve argüman ile tanıtılır.
2. Genellikle n00b hataları hakkında yorum yaparken, bir süredir bildiği birkaç kişi tarafından bilinen bir takımın göz kırpmasıyla paylaşılıyor
3. çok geçmeden akılsızca binlerce kişi tarafından açıklamayı asla okumayan, ancak düşünmemek için bir bahane olarak ve başkalarından daha üstün hissetmek için ucuz ve kolay bir yol olarak kullanmayı seviyorum
4. Sonunda, hiçbir makul borçlanma “meme” gelgitine neden olamaz - ve paradigma din ve dogmaya dönüşür.

Başlangıçta n00b'lerin aydınlanmasına öncülük etmesi amaçlanan meme şimdi bilinçsizce kendilerini kandırmak için bir kulüp olarak kullanılıyor.

Kompozisyon ve kalıtım çok farklı şeylerdir ve birbirleriyle karıştırılmamalıdır. Kompozisyonun birçok fazla çalışma ile mirası simüle etmek için kullanılabileceği doğru olsa da , bu mirası ikinci sınıf bir vatandaş yapmaz ve kompozisyonu favori oğlu yapmaz. Birçok n00b'nin devralmayı kısayol olarak kullanmaya çalışması, mekanizmayı geçersiz kılmaz ve neredeyse tüm n00b'ler hatadan ders alır ve böylece geliştirir.

Lütfen DÜŞÜNÜN senin tasarımları hakkında, sloganlar spouting durdurun.

</ Rant>

Deneyim.

Sizin dediğiniz gibi onların farklı işlerin araçları olduklarını, ancak ifadenin ortaya çıktığını çünkü insanların bu şekilde kullanmadıklarını söyledi.

Kalıtım esas olarak polimorfik bir araçtır, ancak bazı insanlar, daha sonraki tehlikelerine rağmen, kodu yeniden kullanma / paylaşma yöntemi olarak kullanmaya çalışırlar. Gerekçe “iyi miras alırsam tüm yöntemleri bedavaya alırım” olmaktır, ancak bu iki sınıfın potansiyel olarak polimorfik bir ilişkiye sahip olmadığı gerçeğini görmezden gelin.

Öyleyse neden devralma üzerine kompozisyonu tercih edelim - basitçe sınıflar arasındaki ilişki polimorfik değildir. İnsanlara diz pisliğinin miras alarak yanıt vermemelerini hatırlatmak için basitçe var olur.

Bu yeni bir fikir değil, 1994'te yayımlanan GoF tasarım desenleri kitabında tanıtıldığına inanıyorum.

Kalıtımın asıl sorunu beyaz kutusudur. Tanım olarak, miras aldığınız sınıfın uygulama ayrıntılarını bilmeniz gerekir. Öte yandan, kompozisyonla, yalnızca oluşturduğunuz sınıfın ortak arabirimini önemsersiniz.

GoF kitabından:

Miras, ebeveyninin uygulamasının ayrıntılarına bir alt sınıf gösterir, genellikle 'mirasın kapsüllemeyi bozduğu' söylenir.

GoF kitabındaki wikipedia makalesinin iyi bir tanıtımı var.

Sorunuzun bir kısmını yanıtlamak için, bu kavramın ilk kez 1994'te yayınlanan GOF Tasarım Modelleri: Yeniden Kullanılabilir Nesne Yönelimli Yazılımlar kitabında göründüğüne inanıyorum .

Kalıtım yerine nesne kompozisyonunu tercih etme

Bu ifadeyi, kompozisyondaki kalıtımın kısa bir karşılaştırması ile ortaya koymaktadır. Asla "miras kullanma" demiyorlar.

"Mirasa ilişkin kompozisyon", "Bir sınıfın verilerinin (veya davranışının) başka bir sınıfa dahil edilmesi gerektiğini hissederken, her zaman mirası kör bir şekilde uygulamadan önce kompozisyonu kullanmayı düşünün" demesinin kısa (ve görünüşte yanıltıcı) bir yoludur.

Bu neden doğru? Çünkü kalıtım, 2 sınıf arasında sıkı, derleme zamanı birleşimi yaratır. Aksine, bileşim gevşek bağlantı olup, diğerleri arasında endişelerin net bir şekilde ayrılmasını, çalışma süresinde bağımlılıkların anahtarlanabilme olasılığını ve daha kolay, daha yalıtılmış bağımlılık test edilebilirliğini sağlar.

Bu sadece kalıtımın dikkatli kullanılması gerektiği anlamına gelir çünkü bir faydası yoktur, bir maliyeti vardır. Aslında, “mirasa ilişkin kompozisyon” genellikle “bağımlılıktan mirasa ilişkin miras” kompozisyonu anlamına gelir çünkü sık sık bağımlılığınızın somut alt sınıftan ziyade soyut bir üst sınıf olmasını istersiniz. Çalışma zamanında bağımlılığınızın farklı somut uygulamaları arasında geçiş yapmanızı sağlar.

Bu nedenle (diğerleri arasında), muhtemelen vanilya mirasından daha fazla arabirim uygulaması veya soyut sınıflar şeklinde kullanılan miras göreceksiniz.

(Mecazi) bir örnek olabilir:

"Bir Yılan sınıfım var ve Yılan ısırdığında ne olacağını bu sınıfın bir parçası olarak eklemek istiyorum. Yılanın Bite () yöntemine sahip bir BiterAnimal sınıfını miras alması ve zehirli ısırığı yansıtmak için bu yöntemi geçersiz kılması için cazip olacağım Fakat Miras Üzerine Kompozisyon beni bir kompozisyon kullanmaya çalışmam gerektiği konusunda uyarıyor ... Benim durumumda bu bir Bite üyesine sahip Snake'e çevrilebilir.Bite sınıfı birkaç alt sınıfa sahip soyut (veya bir arayüz) olabilir. VenomousBite ve DryBite alt sınıflarına sahip olmak ve yılanın yaşlandıkça aynı Snake örneğindeki ısırığı değiştirebilmek gibi güzel şeyler.Ayrıca, bir Bite'nın tüm etkilerini kendi sınıfında kullanmak, onu bu Frost sınıfında tekrar kullanmama izin verebilir , çünkü don ısırır, ancak bir BiterAnimal değildir, vb ... "

Kompozisyon için bazı olası argümanlar:

Kompozisyon biraz daha fazla dil / çerçeve agnostik
Kalıtımdır ve neyi uygular / ister / sağlar / ne sağlar? Alt / üst sınıfın erişebildiği ve sanal yöntemleri olan performansları neler olabilir? çok az dil desteği ve dolayısıyla farklı platformlar / çerçevelerdeki uygulamalar kompozisyon desenlerini daha kolay paylaşabilir.

Kompozisyon nesneler inşa etmenin çok basit ve dokunsal bir yoludur
Kalıtımın anlaşılması kolaydır, fakat yine de gerçek hayatta olduğu gibi kolayca gösterilemez. Gerçek hayatta birçok nesne parçalara ayrılarak oluşturulabilir. Diyelim ki bir bisiklet iki tekerlek, bir çerçeve, bir koltuk, bir zincir vb. Kullanılarak yapılabilir. Bir kalıtım metaforunda, bir bisikletin bir tek tekerlekli sirk bisikletine uzandığını söyleyebilirim, bir miktar uygulanabilir ancak yine de gerçek görüntüden kompozisyondan çok daha ileride. (Açıkçası bu çok iyi bir kalıtım örneği değil, ama aynı kalır). Kalıtım kelimesi bile (en azından beklediğim çoğu ABD İngilizcesi konuşmacıları) bile, yazılımdaki anlamı ile bir bağlantısı olan, ancak yine de sadece gevşek bir şekilde uyuyan "ölmüş bir akrabadan bir şey geçti" çizgileri boyunca otomatik olarak bir anlam ifade ediyor.

Kompozisyon neredeyse her zaman daha esnektir Kompozisyonu
kullanarak her zaman kendi davranışınızı tanımlamayı seçebilir veya yalnızca kompozisyon bölümlerinizin o bölümünü gösterebilirsiniz. Bu şekilde miras hiyerarşisi (sanal vs sanal olmayan vb.) Tarafından getirilebilecek hiçbir kısıtlama ile karşılaşmazsınız.

Öyleyse, Kompozisyon doğal olarak kalıtımdan daha az teorik kısıtlamaları olan daha basit bir metafor olabilir. Ayrıca, bu özel nedenler tasarım süresi boyunca daha belirgin olabilir veya kalıtımın bazı acı noktalarıyla uğraşırken ortaya çıkabilir.

Yasal Uyarı:
Açıkçası bu kesin değil / tek yönlü bir cadde değil. Her tasarım, çeşitli kalıpların / araçların değerlendirilmesini hak eder. Kalıtım yaygın olarak kullanılır, birçok faydası vardır ve çoğu zaman kompozisyondan daha şıktır. Bunlar, kompozisyonu tercih ederken kullanılabilecek bazı olası nedenlerdir.

Belki de son birkaç ay içinde bunu söyleyen insanları fark ettiniz, ancak bundan daha uzun süredir iyi programcılar tarafından biliniyor. Ben kesinlikle yaklaşık on yıldır uygun olan yerlerde söylüyorum.

Konseptin amacı, kalıtımın üstünde büyük bir kavramsal yük olduğudur. Kalıtım kullanıyorsanız, her bir yöntem çağrısının içinde gizli bir gönderme olur. Derin bir miras ağacınız veya birden fazla gönderiminiz varsa (veya daha da kötüsü) varsa, belirli bir çağrıda belirli bir yöntemin nereye gönderileceğini bulmak, kraliyet PITA'sına dönüşebilir. Kod hakkında doğru muhakeme yapmayı daha karmaşık hale getirir ve hata ayıklamayı zorlaştırır.

Göstermek için basit bir örnek vereyim. Bir miras ağacının derinliklerinde, birinin yöntem olarak adlandırıldığını varsayalım foo. Sonra bir başkası gelir ve fooağacın tepesine ekler , ancak farklı bir şey yapıyor. (Bu durum çoklu mirasta daha yaygındır.) Artık kök sınıfta çalışan kişi belirsiz çocuk sınıfını kırmıştır ve muhtemelen bunu anlamamıştır. Ünite testleri ile% 100 kapsama sahip olabilirsiniz ve bu kırılmayı fark edemezsiniz; çünkü üstteki kişi çocuk sınıfını test etmeyi düşünmezdi ve çocuk sınıfının testleri üstte yaratılan yeni yöntemleri test etmeyi düşünmüyor. . (Kuşkusuz, bunu yakalayacak birim testleri yazmanın yolları vardır, ancak bu şekilde testleri kolayca yazamayacağınız durumlar da vardır.)

Aksine, kompozisyon kullandığınızda, her aramada, aramayı neye gönderdiğiniz genellikle daha açıktır. (Tamam, örneğin bağımlılık enjeksiyonuyla kontrolün tersini kullanıyorsanız, o zaman aramanın nereye gittiğini bulmak da sorunlu olabilir. Ancak, genellikle bunu anlamak daha kolaydır.) Bu, mantıklı olmayı kolaylaştırır. Bir bonus olarak, kompozisyon birbirinden ayrılmış metotlara yol açar. Yukarıdaki örnek orada olmamalıdır çünkü çocuk sınıfı belirsiz bir bileşene taşınır ve çağrının foobelirsiz bileşen için mi yoksa ana nesne için mi yapıldığına dair hiçbir soru yoktur .

Şimdi miras ve kompozisyonun iki farklı şeye hizmet eden iki farklı araç olduğu konusunda kesinlikle haklısın. Elbette kalıtım kavramsal yükü taşır, ancak iş için doğru araç olduğunda, kullanmaya çalışmaktan ve sizin için ne yaptığını elden yapmaya çalışmaktan daha az kavramsal yük taşır. Ne yaptıklarını bilen hiç kimse, asla miras almamanız gerektiğini söyleyemez. Ancak yapılacak doğru şey olduğundan emin olun.

Maalesef birçok geliştirici nesne yönelimli yazılımları öğrenir, kalıtım hakkında bilgi edinir ve ardından yeni baltalarını mümkün olduğunca sık kullanmaya gider. Bu, kompozisyonun doğru araç olduğu kalıtımı kullanmaya çalıştıkları anlamına gelir. Umarım zamanla daha iyi öğreneceklerdir, ancak sık sık bu, birkaç kaldırılmış uzuv vb.

OO'nun yeni başlayanların ihtiyaç duymadıkları zaman kalıtımı kullanma eğiliminde olduğu gözlemine verilen tepki. Kalıtım kesinlikle kötü bir şey değildir, ancak aşırı kullanılabilir. Bir sınıf sadece diğerinden işlevselliğe ihtiyaç duyarsa, kompozisyon muhtemelen işe yarayacaktır. Diğer durumlarda, miras işe yarar ve kompozisyon çalışmaz.

Bir sınıftan miras almak birçok şeyi ima eder. Bir Derived'in bir Base tipi olduğu anlamına gelir ( kanyon detayları için Liskov İkame prensibine bakın). Bazlı korumalı üyelere ve üye fonksiyonlarına Türetilmiş erişim sağlar. Bu yakın bir ilişkidir, yani yüksek bağlaşmaya sahiptir ve birinde yapılan değişikliklerin diğerinde değişiklik yapması daha muhtemeldir.

Eşleştirme kötü bir şey. Programların anlaşılmasını ve değiştirilmesini zorlaştırır. Diğer şeyler eşit olmak üzere, her zaman daha az bağlantı içeren seçeneği seçmelisiniz.

Bu nedenle, eğer bir kompozisyon ya da miras işi etkin bir şekilde yapacaksa, kompozisyonu seçin, çünkü daha düşük birleşmedir. Eğer kompozisyon işi etkili bir şekilde yapmazsa ve miras alırsa, miras almayı seçmelisin, çünkü yapmak zorundasın.

İşte benim iki kuruş (zaten yükseltilmiş tüm mükemmel noktaların ötesinde):

IMHO, Programcıların çoğunun gerçekten miras almadığı ve kısmen bu kavramın nasıl öğretildiğinin bir sonucu olarak, aşırıya kaçma gerçeği ortaya çıkıyor. Bu kavram, nasıl doğru yapmaları gerektiğini öğretmeye odaklanmak yerine onları aşırıya kaçmalarını engellemeye çalışmanın bir yolu olarak var.

Öğretmek veya mentorluk yapmak için zaman harcayan herkes, özellikle diğer paradigmalarda tecrübesi olan yeni geliştiricilerle bunun ne olduğunu bilir:

Bu geliştiriciler başlangıçta kalıtımın bu korkutucu kavram olduğunu düşünüyor. Bu yüzden ara yüzleri örtüşen tiplerle (ör. Ortak alt tiplendirme olmadan aynı belirlenmiş davranış) ve ortak işlevsellik parçalarını uygulamak için küreselleştiler.

Sonra (çoğu zaman aşırı öğretmenin bir sonucu olarak), kalıtımın faydalarını öğrenir, ancak çoğu zaman yeniden kullanılması için hepsini yakala çözümü olarak öğretilir. Herhangi bir ortak davranışın kalıtım yoluyla paylaşılması gerektiğine dair bir algıyla son bulurlar. Bunun nedeni, odaklamanın alt türleme yapmaktan ziyade uygulama kalıtımı üzerine olmasıdır.

Vakaların% 80'inde bu yeterince iyi. Fakat diğer% 20 ise sorunun başladığı yer. Yeniden yazmaktan kaçınmak ve uygulama paylaşımından faydalandıklarından emin olmak için, temel soyutlamaları yerine amaçlanan uygulama etrafında hiyerarşilerini tasarlamaya başlarlar. "Yığın çift bağlantılı listeden miras kalmıştır" buna güzel bir örnektir.

Öğretmenlerin çoğu, bu noktada arayüz kavramını tanıtmakta ısrar etmemektedir, çünkü bu başka bir kavramdır veya (C ++ 'da), bu aşamada öğretilmeyen soyut sınıfları ve çoklu kalıtım kullanarak onları taklit etmeniz gerektiği için. Java'da, birçok öğretmen "çoklu kalıtım yok" veya "çoklu kalıtım kötüdür" ifadelerini arayüzlerin öneminden ayırmaz.

Tüm bunlar, uygulama mirası ile gereksiz kod yazmak zorunda olmamanın güzelliğini o kadar çok şey öğrenmiş olduğumuzla birleşiyor: tonlarca basit delegasyon kodu doğal değil. Bu yüzden kompozisyon dağınık görünüyor, bu yüzden yeni programcıları tekrar kullanmaya zorlamak için bu kurallara ihtiyacımız var.

Yorumlardan birinde Mason, bir gün zararlı olduğu düşünülen Miras hakkında konuşacağımızı söyledi .

Umarım.

Kalıtım problemi bir kerede basittir ve ölümcül bir kavramın bir fonksiyonelliğe sahip olması gerektiği fikrine saygı duymaz.

Çoğu OO dilinde, bir temel sınıftan miras alırken:

• arayüzünden devralır
• Uygulamasından devralmak (hem veri hem de yöntem)

Ve işte sorun haline geldi.

Bu değil 00-dil çoğunlukla onunla sıkışmış olsa sadece bir yaklaşım. Neyse ki arayüzlerde / soyut sınıflarda var.

Ayrıca, aksi takdirde yapmanın kolay olmayışı, büyük ölçüde kullanılmasına katkıda bulunur: açıkçası, bunu bilseniz bile, bir arabirimden miras alırsınız ve temel sınıfı yöntem çağrıları delegasyonunu yaparak kompozisyona katıştırır mısınız? Yine de daha iyi olurdu, eğer aniden arayüzde yeni bir yöntem ortaya çıkarsa ve onu nasıl uygulayacağınızı bilinçli olarak seçmek zorunda kalırsanız bile uyarılırsınız.

Bir sayaç noktası olarak, Haskellyalnızca Liskov Prensibi'ni saf arayüzlerden (kavramlar denir) "türetirken" kullanmaya izin verin (1). Mevcut bir sınıftan türetemezsiniz, yalnızca kompozisyon verilerini yerleştirmenize izin verir.

(1) kavramlar bir uygulama için makul bir varsayılan sağlayabilir, ancak hiçbir veriye sahip olmadıkları için, bu varsayılan sadece konsept tarafından önerilen diğer yöntemler veya sabitler olarak tanımlanabilir.

Basit cevap şudur: miras, kompozisyondan daha fazla birliğe sahiptir. İki seçenek, eşdeğer niteliklere sahip iki seçenek göz önüne alındığında, daha az bağlı olanı seçin.

Bence bu tür bir tavsiye "uçmayı tercih et" demeye benziyor. Yani, uçakların otomobillere göre her türlü avantajı var, ancak bu kesin bir karmaşıklıkla geliyor. Bu yüzden eğer birçok insan şehir merkezinden banliyölere uçmaya çalışırsa, gerçekten, gerçekten duymaları gereken tavsiye , uçmaları gerekmediğidir ve aslında, uçmak onu uzun vadede daha karmaşık hale getirecektir. Kısa vadede serin / verimli / kolay gibi görünse de. Ne zaman Oysa do uçmak gerekir, genellikle belirgin olması gerekiyor.

Aynı şekilde, miras, kompozisyonun yapamayacağı şeyleri yapabilir, ancak ihtiyacınız olduğunda değil, ihtiyacınız olduğunda bunu kullanmalısınız. Öyleyse, istemediğiniz zaman mirasa ihtiyacınız olduğunu varsaymaya hiç hevesli değilseniz, “kompozisyonu tercih etme” tavsiyesine ihtiyacınız yoktur. Ama pek çok insan yapmak ve bunu bu tavsiyeye ihtiyacım var.

Gerçekten mirasa ihtiyaç duyduğunuzda, bunun bariz olduğu ve sonra kullanmanız gerektiği açık olmalı.

Ayrıca, Steven Lowe'ın cevabı. Gerçekten, gerçekten bu.

Kalıtım doğal olarak kötü değildir ve kompozisyon doğal olarak iyi değildir. Bunlar sadece bir OO programcısının yazılım tasarlamak için kullanabileceği araçlardır.

Bir sınıfa baktığınızda, kesinlikle gerekenden fazlasını yapıyor mu ( SRP )? Gereksiz bir şekilde ( DRY ) çoğaltma işlevi mi , yoksa diğer sınıfların ( Feature Envy ) özellikleri veya yöntemleriyle aşırı derecede ilgileniyor mu? Eğer sınıf bütün bu kavramları ihlal ediyorsa (ve muhtemelen daha fazlası), bir Tanrı Sınıfı olmaya çalışıyor mu ? Bunlar, hiçbiri bir miras problemi olmayan, ancak tasarımı hızlıca ortaya çıkarabilecek, ancak polimorfizmin uygulandığı yerlerde büyük baş ağrıları ve kırılgan bağımlılıklar yaratabilen bir takım problemlerdir.

Sorunun kökü, kalıtım hakkında daha az bir anlayış eksikliği olabilir ve tasarım açısından zayıf tercihlerden biri olabilir veya belki de Tek Sorumluluk Prensibi'ne uymayan sınıflarla ilgili "kod kokularını" tanımıyor olabilir . Polimorfizm ve Liskov Değiştirmenin kompozisyon lehine atılmasına gerek yoktur. Polimorfizmin kendisi mirasa güvenmeksizin uygulanabilir, bunlar tamamen ücretsiz kavramlardır. Dikkatlice uygulanırsa. İşin püf noktası, kodunuzu basit ve temiz tutmayı ve sağlam bir sistem tasarımı oluşturmak için oluşturmanız gereken sınıfların sayısı konusunda fazla endişelenmekten vazgeçmemeyi hedeflemektir.

Mirastan yana bir kompozisyon lehine olana gelince, bu gerçekten çözülen problem açısından en anlamlı olan tasarım öğelerinin düşünceli bir şekilde uygulanması durumudur. Eğer yoksa ihtiyaç davranışı miras, o zaman muhtemelen kompozisyon uyumsuzluklar ve başlıca üstlenmeden çabaları sonradan önlemek için yardımcı olacaktır olmamalıdır olarak. Öte yandan, çoğaltmanın benzer sınıfların bir grubuna odaklanacağı şekilde çok sayıda kod tekrarladığınızı fark ederseniz, ortak bir ata oluşturmanın aynı çağrı ve sınıfların sayısını azaltmaya yardımcı olabileceği anlamına gelir. Her sınıf arasında tekrar etmeniz gerekebilir. Bu nedenle, kompozisyonu tercih ediyorsunuz, ancak mirasın asla geçerli olmadığını varsaymıyorsunuz.

Asıl alıntı, sanırım, bölümlerden birinin adı olan Joshua Bloch'un "Etkin Java'sından" geliyor. Kalıtımın bir paket içinde ve bir sınıfın uzatma için özel olarak tasarlandığı ve belgelendiği her yerde güvenli olduğunu iddia eder. Diğerlerinin de belirttiği gibi, mirasın kapsüllemeyi bozduğunu, çünkü bir alt sınıfın, üst sınıfının uygulama detaylarına bağlı olduğunu iddia ediyor. Bu, kırılganlığa yol açtığını söylüyor.

Her ne kadar bahsetmese de, bana öyle geliyor ki, Java'daki tek miras, kompozisyonun size mirastan çok daha fazla esneklik kazandırdığı anlamına geliyor.