Çoklu kalıtımla ilgili kesin sorun nedir?

İnsanların sürekli olarak C # veya Java'nın bir sonraki sürümüne çoklu mirasın dahil edilip edilmeyeceğini sorduğunu görebiliyorum. Bu yeteneğe sahip olacak kadar şanslı olan C ++ arkadaşları, bunun birisine sonunda kendilerini asması için bir ip vermek gibi olduğunu söylüyorlar.

Çoklu mirasın sorunu nedir? Somut örnekler var mı?

En belirgin sorun, işlevin geçersiz kılınmasıdır.

Diyelim ki iki sınıfımız var Ave Bher ikisi de bir yöntemi tanımlıyor doSomething. Şimdi üçüncü bir sınıfını tanımlamak Chem, devralır Ave Bfakat geçersiz kılmaz doSomethingyöntemi.

Derleyici bu kodu tohumladığında ...

C c = new C();
c.doSomething();

... yöntemin hangi uygulamasını kullanmalıdır? Daha fazla açıklama yapılmadan derleyicinin belirsizliği çözmesi imkansızdır.

Geçersiz kılmanın yanı sıra, çoklu kalıtımla ilgili diğer büyük sorun, fiziksel nesnelerin bellekteki düzenidir.

C ++, Java ve C # gibi diller, her nesne türü için sabit bir adres tabanlı düzen oluşturur. Bunun gibi bir şey:

class A:
    at offset 0 ... "abc" ... 4 byte int field
    at offset 4 ... "xyz" ... 8 byte double field
    at offset 12 ... "speak" ... 4 byte function pointer

class B:
    at offset 0 ... "foo" ... 2 byte short field
    at offset 2 ... 2 bytes of alignment padding
    at offset 4 ... "bar" ... 4 byte array pointer
    at offset 8 ... "baz" ... 4 byte function pointer

Derleyici makine kodu (veya bayt kodu) ürettiğinde, her yönteme veya alana erişmek için bu sayısal uzaklıkları kullanır.

Çoklu miras, işi çok zorlaştırır.

Sınıf ise Chem devralır Ave B, derleyici veri düzeni karar vermek vardır ABsırayla veya BAsırayla.

Ama şimdi bir Bnesnede yöntemleri çağırdığınızı hayal edin . Gerçekten sadece bir Bmi? Yoksa arayüzü Caracılığıyla polimorfik olarak adlandırılan bir nesne Bmi? Nesnenin gerçek kimliğine bağlı olarak, fiziksel düzen farklı olacaktır ve çağrı yerinde çalıştırılacak işlevin ofsetini bilmek imkansızdır.

Bu tür bir sistemi ele almanın yolu, sabit yerleşim yaklaşımından vazgeçmek, her nesnenin işlevleri çağırmadan veya alanlarına erişmeden önce düzeni için sorgulanmasına izin vermektir .

Yani ... uzun lafın kısası ... derleyici yazarların çoklu mirası desteklemesi baş belasıdır. Yani Guido van Rossum gibi biri python tasarladığında veya Anders Hejlsberg c # tasarladığında, çoklu mirası desteklemenin derleyici uygulamalarını önemli ölçüde daha karmaşık hale getireceğini biliyorlar ve muhtemelen faydanın maliyete değdiğini düşünmüyorlar.

Bahsettiğiniz sorunları çözmek o kadar da zor değil. Aslında, örneğin Eiffel bunu çok iyi yapıyor! (ve keyfi seçimler ya da herhangi bir şey yapmadan)

Örneğin, her ikisi de foo () yöntemine sahip A ve B'den miras alırsanız, o zaman elbette C sınıfınızda hem A hem de B'den miras alan keyfi bir seçim istemezsiniz. c.foo () çağrılırsa veya C'deki yöntemlerden birini yeniden adlandırmanız gerekirse kullanılır (bar () olabilir)

Ayrıca çoklu kalıtımın genellikle oldukça yararlı olduğunu düşünüyorum. Eyfel kütüphanelerine bakarsanız, her yerde kullanıldığını görürsünüz ve kişisel olarak Java'da programlamaya geri dönmem gerektiğinde bu özelliği kaçırdım.

Elmas sorunu :

iki B ve C sınıfı A'dan miras aldığında ve D sınıfı hem B hem de C'den miras aldığında ortaya çıkan bir belirsizlik A'da B ve C'nin geçersiz kıldığı ve D'nin onu geçersiz kılmadığı bir yöntem varsa, o zaman yöntem D miras alır: B'ninki mi yoksa C'ninki mi?

... Bu durumda sınıf kalıtım diyagramının şekli nedeniyle "elmas problemi" olarak adlandırılır. Bu durumda, A sınıfı üstte, hem B hem de C altında ayrı ayrı ve D, bir elmas şekli oluşturmak için altta ikisini birleştiriyor ...

Çoklu miras, sıklıkla kullanılmayan ve kötüye kullanılabilen, ancak bazen gerekli olan şeylerden biridir.

İyi bir alternatif olmadığında kötüye kullanılabileceği için bir özellik eklemeyi asla anlamadım. Arayüzler, çoklu kalıtıma alternatif değildir. Birincisi, ön koşulları veya son koşulları uygulamanıza izin vermiyorlar. Diğer herhangi bir araç gibi, ne zaman ve nasıl kullanılacağını bilmeniz gerekir.

Diyelim ki, her ikisi de C tarafından miras alınan A ve B nesneleriniz var. A ve B'nin her ikisi de foo () uyguluyor ve C bunu yapmıyor. C.foo () diyorum. Hangi uygulama seçilir? Başka sorunlar da var ama bu tür şeyler çok büyük.

Çoklu kalıtımla ilgili temel sorun, tloach'ın örneğiyle güzel bir şekilde özetlenmiştir. Aynı işlevi veya alanı uygulayan birden çok temel sınıftan miras alırken, derleyicinin hangi uygulamanın devralınacağına karar vermesi gerekir.

Aynı temel sınıftan miras alan birden çok sınıftan miras aldığınızda bu daha da kötüleşir. (elmas miras, miras ağacını çizerseniz bir elmas şekli alırsınız)

Bu sorunlar, bir derleyicinin üstesinden gelmesi için gerçekten sorunlu değildir. Ancak derleyicinin burada yapması gereken seçim oldukça keyfi, bu da kodu çok daha az sezgisel hale getiriyor.

İyi bir OO tasarımı yaparken asla çoklu mirasa ihtiyacım olmadığını görüyorum. İhtiyaç duyduğum durumlarda, kalıtımı genellikle işlevselliği yeniden kullanmak için kullandığımı, kalıtım ise yalnızca "is-a" ilişkileri için uygun olduğunu görüyorum.

Aynı sorunları çözen ve çoklu kalıtımın sahip olduğu sorunları olmayan mixins gibi başka teknikler de vardır.

Elmas sorununun bir sorun olduğunu düşünmüyorum, bu safsatayı düşünürdüm, başka bir şey değil.

Benim bakış açıma göre, çoklu kalıtımla ilgili en kötü sorun, RAD - kurbanlar ve geliştirici olduklarını iddia eden ancak gerçekte yarı bilgiyle (en iyi ihtimalle) sıkışmış insanlar.

Kişisel olarak, nihayet Windows Formlarında böyle bir şey yapabilseydim çok mutlu olurdum (bu doğru kod değil, ama size fikri vermeli):

public sealed class CustomerEditView : Form, MVCView<Customer>

Birden fazla mirasa sahip olmamamdaki ana sorun bu. Arayüzlerle benzer bir şey YAPABİLİRSİNİZ, ancak benim "s *** kodu" dediğim şey var, örneğin bir veri bağlamı elde etmek için sınıflarınızın her birine yazmanız gereken bu acı verici tekrarlayan c ***.

Kanımca, modern bir dilde HERHANGİ bir kod tekrarına kesinlikle gerek yok, en ufak bir gerek yok.

Common Lisp Nesne Sistemi (CLOS), C ++ tarzı problemlerden kaçınırken MI'yı destekleyen bir şeye başka bir örnektir: kalıtıma mantıklı bir varsayılan verilirken, yine de size, örneğin bir süperin davranışını tam olarak nasıl arayacağınıza açıkça karar verme özgürlüğü sağlar. .

Çoklu mirasın kendisinde yanlış bir şey yoktur. Sorun, başlangıçtan itibaren çoklu miras akılda tutularak tasarlanmamış bir dile çoklu kalıtım eklemektir.

Eyfel dili, çok verimli ve üretken bir şekilde, kısıtlama olmaksızın çoklu mirası destekliyor, ancak dil o baştan itibaren onu desteklemek için tasarlandı.

Bu özelliğin derleyici geliştiricileri için uygulanması karmaşıktır, ancak bu dezavantajın, iyi bir çoklu kalıtım desteğinin diğer özelliklerin desteğini önleyebilmesi (yani Arayüz veya Genişletme Yöntemine gerek olmaması) ile telafi edilebileceği görülmektedir.

Bence çoklu mirası destekleyip desteklememenin daha çok bir seçim meselesi, bir öncelik meselesi. Daha karmaşık bir özelliğin doğru şekilde uygulanması ve çalıştırılması daha fazla zaman alır ve daha tartışmalı olabilir. C ++ uygulaması, C # ve Java'da çoklu kalıtımın uygulanmamasının nedeni olabilir ...

Java ve .NET gibi çerçevelerin tasarım hedeflerinden biri, derlenmiş kodun önceden derlenmiş bir kitaplığın bir sürümüyle çalışmasını, bu kitaplığın sonraki sürümleriyle eşit derecede iyi çalışmasını sağlamaktır. yeni özellikler ekleyin. C veya C ++ gibi dillerdeki normal paradigma, ihtiyaç duydukları tüm kitaplıkları içeren statik olarak bağlantılı yürütülebilir dosyaları dağıtmak iken, .NET ve Java'daki paradigma, uygulamaları çalışma zamanında "bağlantılı" bileşen koleksiyonları olarak dağıtmaktır. .

.NET'ten önce gelen COM modeli bu genel yaklaşımı kullanmayı denedi, ancak gerçekten mirası yoktu - bunun yerine, her sınıf tanımı hem bir sınıfı hem de tüm ortak üyelerini içeren aynı ada sahip bir arabirimi etkin bir şekilde tanımladı. Örnekler sınıf türündeyken başvurular arabirim türündeydi. Bir sınıfın başka bir sınıftan türetildiğinin bildirilmesi, bir sınıfın diğerinin arabirimini uyguladığını bildirmeye eşdeğerdi ve yeni sınıfın, türetildiği sınıfların tüm genel üyelerini yeniden uygulamasını gerektiriyordu. Y ve Z, X'ten türetilirse ve W, Y ve Z'den türetilirse, Y ve Z'nin X'in üyelerini farklı şekilde uygulamalarının bir önemi yoktur, çünkü Z, uygulamalarını kullanamayacaktır - kendi. W, Y ve / veya Z örneklerini kapsayabilir,

Java ve .NET'teki zorluk, kodun üyeleri devralmasına izin verilmesi ve onlara dolaylı olarak üst üyelere başvuruda bulunmasına izin verilmesidir . Yukarıdaki gibi WZ ile ilgili sınıfların olduğunu varsayalım:

class X { public virtual void Foo() { Console.WriteLine("XFoo"); }
class Y : X {};
class Z : X {};
class W : Y, Z  // Not actually permitted in C#
{
  public static void Test()
  {
    var it = new W();
    it.Foo();
  }
}

Görünüşe W.Test()göre bir W örneği oluşturmak, içinde Footanımlanan sanal yöntemin uygulamasını çağırmalı X. Bununla birlikte, Y ve Z'nin aslında ayrı olarak derlenmiş bir modülde olduğunu ve X ve W derlendiğinde yukarıdaki gibi tanımlanmalarına rağmen, daha sonra değiştirilip yeniden derlendiğini varsayalım:

class Y : X { public override void Foo() { Console.WriteLine("YFoo"); }
class Z : X { public override void Foo() { Console.WriteLine("ZFoo"); }

Şimdi aramanın etkisi ne olmalı W.Test()? Programın dağıtımdan önce statik olarak bağlanması gerekiyorsa, statik bağlantı aşaması, programın Y ve Z değiştirilmeden önce hiçbir belirsizliği olmasa da, Y ve Z'deki değişikliklerin her şeyi belirsiz hale getirdiğini ve bağlayıcının bunu reddedebileceğini fark edebilir. bu tür bir belirsizlik çözülmedikçe veya çözülene kadar programı oluşturun. Öte yandan, hem W hem de Y ve Z'nin yeni sürümlerine sahip olan kişinin, programı çalıştırmak isteyen ve hiçbiri için kaynak kodu olmayan biri olması mümkündür. Ne zaman W.Test()çalıştığı artık net olmayacakW.Test() yapmalı, ancak kullanıcı W'yi Y ve Z'nin yeni sürümüyle çalıştırmayı deneyene kadar, sistemin herhangi bir parçasının bir sorun olduğunu fark etmesi mümkün olmayacaktı (W, Y ve Z'deki değişikliklerden önce bile yasadışı kabul edilmediği sürece) .

Elmas Eğer sürece bir sorun değildir do not C ++ sanal miras gibi bir şey kullanın: Her temel sınıf (aslında onlar RAM içinde bu şekilde ortaya koydu) üyesi alanını andıran Normal devralma bazı sözdizimsel şeker veren ve bir daha fazla sanal yöntemi geçersiz kılmak için ekstra yetenek. Bu, derleme sırasında bazı belirsizlikler ortaya çıkarabilir, ancak bu genellikle çözülmesi kolaydır.

Öte yandan, sanal kalıtım ile çok kolay bir şekilde kontrolden çıkar (ve sonra bir karmaşa haline gelir). Örnek olarak bir "kalp" diyagramı düşünün:

  A       A
 / \     / \
B   C   D   E
 \ /     \ /
  F       G
    \   /
      H

C ++ tamamen imkansızdır: yakında kadar Fve Gtek sınıfa birleştirilir, bunların Aler de dönem birleştirilir. Eğer ++ taban sınıfları C matlaşı- düşünün asla Bu demektir ki (bu örnekte sen inşa etmek zorunda Aiçinde Hbilmek zorunda böylece o hiyerarşisinde mevcut yerde). Ancak diğer dillerde işe yarayabilir; örneğin Fve GA'yı açıkça "dahili" olarak ilan edebilir, dolayısıyla sonuçta birleşmeyi yasaklayabilir ve kendilerini etkili bir şekilde sağlamlaştırabilir.

Diğer bir ilginç bir örnektir ( değil C ++ - özel):

  A
 / \
B   B
|   |
C   D
 \ /
  E

Burada yalnızca Bsanal miras kullanır. Yani aynı şeyi paylaşan Eiki Bs içerir A. Bu şekilde, bir elde edebilirsiniz A*işaret ettiği işaretçi E, ancak bir o döküm olamaz B*nesne rağmen pointer ise aslında B böyle dökme belirsiz olarak ve derleyici görür sürece bu belirsizlik (derleme sırasında tespit edilemez tüm program). İşte test kodu:

struct A { virtual ~A() {} /* so that the class is polymorphic */ };
struct B: virtual A {};
struct C: B {};
struct D: B {};
struct E: C, D {};

int main() {
        E data;
        E *e = &data;
        A *a = dynamic_cast<A *>(e); // works, A is unambiguous
//      B *b = dynamic_cast<B *>(e); // doesn't compile
        B *b = dynamic_cast<B *>(a); // NULL: B is ambiguous
        std::cout << "E: " << e << std::endl;
        std::cout << "A: " << a << std::endl;
        std::cout << "B: " << b << std::endl;
// the next casts work
        std::cout << "A::C::B: " << dynamic_cast<B *>(dynamic_cast<C *>(e)) << std::endl;
        std::cout << "A::D::B: " << dynamic_cast<B *>(dynamic_cast<D *>(e)) << std::endl;
        std::cout << "A=>C=>B: " << dynamic_cast<B *>(dynamic_cast<C *>(a)) << std::endl;
        std::cout << "A=>D=>B: " << dynamic_cast<B *>(dynamic_cast<D *>(a)) << std::endl;
        return 0;
}

Dahası, uygulama çok karmaşık olabilir (dile bağlıdır; bencismith'in cevabına bakınız).