[oop] 다중 상속의 정확한 문제는 무엇입니까?

가장 명백한 문제는 함수 재정의입니다.

하자 두 개의 클래스가 있다고 가정 A하고 B하는 방법을 정의하는 두 가지 모두를 doSomething. 이제 및 C둘 다에서 상속되는 세 번째 클래스를 정의 하지만 메서드를 재정의하지 않습니다 .ABdoSomething

컴파일러가이 코드를 시드하면 …

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

… 방법의 어떤 구현을 사용해야합니까? 더 이상의 설명이 없으면 컴파일러가 모호성을 해결할 수 없습니다.

재정의 외에도 다중 상속의 또 다른 큰 문제는 메모리에있는 물리적 개체의 레이아웃입니다.

C ++, Java 및 C #과 같은 언어는 각 객체 유형에 대해 고정 주소 기반 레이아웃을 만듭니다. 이 같은:

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

컴파일러가 기계어 코드 (또는 바이트 코드)를 생성 할 때 해당 숫자 오프셋을 사용하여 각 메서드 또는 필드에 액세스합니다.

다중 상속은 매우 까다 롭습니다.

클래스 C가 A및 둘 다에서 상속하는 경우 B컴파일러는 데이터를 AB순서대로 레이아웃할지 아니면 순서대로 레이아웃할지 결정해야합니다 BA.

그러나 이제 B객체 에 대해 메서드를 호출한다고 상상해보십시오 . 정말 그냥 B? 아니면 실제로 인터페이스를 C통해 다형 적으로 호출 되는 객체 B입니까? 개체의 실제 ID에 따라 물리적 레이아웃이 달라지며 호출 사이트에서 호출 할 함수의 오프셋을 알 수 없습니다.

이러한 종류의 시스템을 처리하는 방법은 고정 레이아웃 접근 방식을 버리고 함수를 호출하거나 해당 필드에 액세스 하기 전에 각 개체의 레이아웃을 쿼리 할 수 ​​있도록하는 것 입니다.

그래서 … 긴 이야기를 짧게 … 컴파일러 작성자가 다중 상속을 지원하는 것은 목에 고통입니다. 따라서 Guido van Rossum과 같은 사람이 파이썬을 설계하거나 Anders Hejlsberg가 c #을 설계 할 때 다중 상속을 지원하는 것이 컴파일러 구현을 훨씬 더 복잡하게 만들 것이라는 것을 알고 있으며, 아마도 그 혜택이 비용의 가치가 있다고 생각하지 않습니다.

답변

public sealed class CustomerEditView : Form, MVCView<Customer>