Vấn đề chính xác với đa kế thừa là gì?

Tôi có thể thấy mọi người luôn hỏi liệu đa kế thừa có nên được đưa vào phiên bản tiếp theo của C # hay Java hay không. Những người trong C ++, những người đủ may mắn có được khả năng này, nói rằng điều này giống như việc cho ai đó một sợi dây để cuối cùng tự treo cổ mình.

Có vấn đề gì với đa kế thừa? Có mẫu bê tông nào không?

Vấn đề rõ ràng nhất là với chức năng ghi đè.

Giả sử có hai lớp Avà Bcả hai đều xác định một phương thức doSomething. Bây giờ bạn xác định một lớp thứ ba C, lớp này kế thừa từ cả Avà B, nhưng bạn không ghi đè doSomethingphương thức.

Khi trình biên dịch bắt nguồn mã này ...

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

... nó nên sử dụng phương pháp thực hiện nào? Nếu không có bất kỳ giải thích rõ ràng nào, trình biên dịch không thể giải quyết sự mơ hồ.

Bên cạnh việc ghi đè, một vấn đề lớn khác với đa kế thừa là cách bố trí các đối tượng vật lý trong bộ nhớ.

Các ngôn ngữ như C ++, Java và C # tạo ra một bố cục dựa trên địa chỉ cố định cho từng loại đối tượng. Một cái gì đó như thế này:

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

Khi trình biên dịch tạo mã máy (hoặc mã bytecode), nó sử dụng các hiệu số đó để truy cập từng phương thức hoặc trường.

Việc thừa kế nhiều lần làm cho nó rất phức tạp.

Nếu lớp Ckế thừa từ cả hai Avà B, trình biên dịch phải quyết định xem có nên bố trí dữ liệu trongAB thứ tự hay theo BAthứ tự.

Nhưng bây giờ hãy tưởng tượng rằng bạn đang gọi các phương thức trên một Bđối tượng. Nó thực sự chỉ là một B? Hay nó thực sự là mộtC đối tượng được gọi là đa hình, thông qua Bgiao diện của nó ? Tùy thuộc vào nhận dạng thực tế của đối tượng, bố cục vật lý sẽ khác nhau và không thể biết được phần bù của hàm để gọi tại trang web gọi.

Cách để xử lý loại hệ thống này là loại bỏ cách tiếp cận bố cục cố định, cho phép từng đối tượng được truy vấn về bố cục của nó trước khi cố gắng gọi các hàm hoặc truy cập các trường của nó.

Vì vậy, ... truyện dài ngắn ... thật là đau đầu cho các tác giả biên dịch để hỗ trợ đa kế thừa. Vì vậy, khi ai đó như Guido van Rossum thiết kế python hoặc khi Anders Hejlsberg thiết kế c #, họ biết rằng việc hỗ trợ đa kế thừa sẽ làm cho việc triển khai trình biên dịch phức tạp hơn đáng kể và có lẽ họ không nghĩ rằng lợi ích đó xứng đáng với chi phí.

Những vấn đề mà các bạn đề cập thực ra không quá khó để giải quyết. Trong thực tế, ví dụ như Eiffel làm điều đó hoàn toàn tốt! (và không giới thiệu các lựa chọn tùy ý hoặc bất cứ điều gì)

Ví dụ: nếu bạn kế thừa từ A và B, cả hai đều có phương thức foo (), thì tất nhiên bạn không muốn có một lựa chọn tùy ý trong lớp C của mình kế thừa từ cả A và B. Bạn phải xác định lại foo để rõ ràng sẽ là gì được sử dụng nếu c.foo () được gọi hoặc nếu không bạn phải đổi tên một trong các phương thức trong C. (nó có thể trở thành bar ())

Ngoài ra tôi nghĩ rằng đa kế thừa thường khá hữu ích. Nếu bạn nhìn vào các thư viện của Eiffel, bạn sẽ thấy rằng nó được sử dụng khắp nơi và cá nhân tôi đã bỏ lỡ tính năng này khi tôi phải quay lại lập trình bằng Java.

Vấn đề kim cương :

một sự mơ hồ nảy sinh khi hai lớp B và C kế thừa từ A và lớp D kế thừa từ cả B và C. Nếu có một phương thức trong A mà B và C đã ghi đè và D không ghi đè nó, thì phiên bản nào của phương thức nào D kế thừa: của B, hay của C?

... Nó được gọi là "vấn đề kim cương" vì hình dạng của sơ đồ kế thừa lớp trong tình huống này. Trong trường hợp này, lớp A ở trên cùng, cả B và C riêng biệt bên dưới nó, và D kết hợp cả hai với nhau ở phía dưới để tạo thành hình thoi ...

Đa kế thừa là một trong những thứ không được sử dụng thường xuyên, và có thể bị lạm dụng, nhưng đôi khi vẫn cần thiết.

Tôi chưa bao giờ hiểu rằng không thêm một tính năng, chỉ vì nó có thể bị sử dụng sai, khi không có lựa chọn thay thế tốt. Giao diện không phải là một sự thay thế cho đa kế thừa. Đối với một, họ không cho phép bạn thực thi các điều kiện trước hoặc điều kiện sau. Cũng giống như bất kỳ công cụ nào khác, bạn cần biết khi nào thích hợp để sử dụng và cách sử dụng nó.

giả sử bạn có các đối tượng A và B đều được kế thừa bởi C. A và B đều triển khai foo () và C thì không. Tôi gọi C.foo (). Việc triển khai nào được chọn? Có những vấn đề khác, nhưng loại vấn đề này là một vấn đề lớn.

Vấn đề chính với đa kế thừa được tóm tắt độc đáo với ví dụ của tloach. Khi kế thừa từ nhiều lớp cơ sở triển khai cùng một chức năng hoặc trường, trình biên dịch phải đưa ra quyết định về việc triển khai nào sẽ kế thừa.

Điều này trở nên tồi tệ hơn khi bạn kế thừa từ nhiều lớp kế thừa từ cùng một lớp cơ sở. (kim cương thừa kế, nếu bạn vẽ cây thừa kế, bạn sẽ có một hình kim cương)

Những vấn đề này không thực sự là vấn đề đối với một trình biên dịch để khắc phục. Nhưng sự lựa chọn mà trình biên dịch phải thực hiện ở đây là khá tùy ý, điều này làm cho mã kém trực quan hơn nhiều.

Tôi thấy rằng khi thiết kế OO tốt, tôi không bao giờ cần đa kế thừa. Trong những trường hợp cần thiết, tôi thường thấy rằng mình đang sử dụng tính năng thừa kế để sử dụng lại chức năng trong khi tính năng thừa kế chỉ thích hợp cho quan hệ "is-a".

Có những kỹ thuật khác như mixin giải quyết các vấn đề tương tự và không có các vấn đề như đa kế thừa.

Tôi không nghĩ vấn đề kim cương là một vấn đề, tôi sẽ coi đó là sự ngụy biện, không có gì khác.

Vấn đề tồi tệ nhất, theo quan điểm của tôi, với đa kế thừa là RAD - nạn nhân và những người tự nhận là nhà phát triển nhưng thực tế lại bị mắc kẹt với một nửa kiến ​​thức (tốt nhất là).

Cá nhân tôi sẽ rất vui nếu cuối cùng tôi có thể làm điều gì đó trong Windows Forms như thế này (nó không phải là mã chính xác, nhưng nó sẽ cung cấp cho bạn ý tưởng):

public sealed class CustomerEditView : Form, MVCView<Customer>

Đây là vấn đề chính mà tôi gặp phải khi không có đa thừa kế. Bạn CÓ THỂ làm điều gì đó tương tự với các giao diện, nhưng có cái mà tôi gọi là "mã s ***", đó là c *** lặp đi lặp lại gây đau đớn này mà bạn phải viết trong mỗi lớp của mình để lấy ngữ cảnh dữ liệu chẳng hạn.

Theo tôi, hoàn toàn không cần, không phải nhỏ nhất, đối với BẤT KỲ sự lặp lại mã nào trong ngôn ngữ hiện đại.

Hệ thống đối tượng Lisp chung (CLOS) là một ví dụ khác về cái gì đó hỗ trợ MI trong khi tránh các vấn đề về kiểu C ++: kế thừa được cung cấp một mặc định hợp lý , trong khi vẫn cho phép bạn tự do quyết định rõ ràng cách chính xác, ví dụ, gọi hành vi của siêu .

Không có gì sai trong bản thân đa kế thừa. Vấn đề là thêm đa kế thừa vào một ngôn ngữ không được thiết kế với đa kế thừa ngay từ đầu.

Ngôn ngữ Eiffel đang hỗ trợ đa kế thừa mà không có hạn chế theo cách rất hiệu quả và hiệu quả nhưng ngôn ngữ này được thiết kế ngay từ đầu để hỗ trợ nó.

Tính năng này rất phức tạp để triển khai đối với các nhà phát triển trình biên dịch, nhưng có vẻ như nhược điểm đó có thể được bù đắp bằng thực tế là hỗ trợ đa kế thừa tốt có thể tránh được sự hỗ trợ của các tính năng khác (tức là không cần Giao diện hoặc Phương thức mở rộng).

Tôi nghĩ rằng hỗ trợ đa kế thừa hay không là vấn đề của sự lựa chọn, vấn đề ưu tiên. Một tính năng phức tạp hơn cần nhiều thời gian hơn để được triển khai và vận hành chính xác và có thể gây tranh cãi nhiều hơn. Việc triển khai C ++ có thể là lý do tại sao đa kế thừa không được triển khai trong C # và Java ...

Một trong những mục tiêu thiết kế của các khuôn khổ như Java và .NET là làm cho mã được biên dịch có thể hoạt động với một phiên bản của thư viện được biên dịch trước, hoạt động tốt như nhau với các phiên bản tiếp theo của thư viện đó, ngay cả khi các phiên bản tiếp theo đó thêm các tính năng mới. Trong khi mô hình thông thường trong các ngôn ngữ như C hoặc C ++ là phân phối các tệp thực thi được liên kết tĩnh có chứa tất cả các thư viện mà chúng cần, mô hình trong .NET và Java là phân phối các ứng dụng dưới dạng tập hợp các thành phần được "liên kết" tại thời điểm chạy .

Mô hình COM trước .NET đã cố gắng sử dụng cách tiếp cận chung này, nhưng nó không thực sự có tính kế thừa - thay vào đó, mỗi định nghĩa lớp xác định hiệu quả cả một lớp và một giao diện cùng tên chứa tất cả các thành viên công khai của nó. Các phiên bản thuộc loại lớp, trong khi các tham chiếu thuộc loại giao diện. Việc khai báo một lớp là dẫn xuất từ ​​lớp khác tương đương với việc khai báo một lớp là triển khai giao diện của lớp kia và yêu cầu lớp mới triển khai lại tất cả các thành viên công khai của các lớp mà lớp đó dẫn xuất từ ​​đó. Nếu Y và Z bắt nguồn từ X và sau đó W bắt nguồn từ Y và Z, sẽ không thành vấn đề nếu Y và Z triển khai các thành viên của X khác nhau, bởi vì Z sẽ không thể sử dụng các triển khai của chúng - nó sẽ phải xác định sở hữu. W có thể bao gồm các trường hợp của Y và / hoặc Z,

Khó khăn trong Java và .NET là mã được phép kế thừa các thành viên và có quyền truy cập vào chúng ngầm tham chiếu đến các thành viên mẹ. Giả sử một có các lớp WZ liên quan như trên:

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();
  }
}

Có vẻ như W.Test()nên tạo một phiên bản của cuộc gọi W để thực hiện phương thức ảo Foođược định nghĩa trong X. Tuy nhiên, giả sử rằng Y và Z thực sự nằm trong một mô-đun được biên dịch riêng và mặc dù chúng được định nghĩa như trên khi X và W được biên dịch, nhưng sau đó chúng đã được thay đổi và biên dịch lại:

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

Bây giờ tác dụng của việc gọi là W.Test()gì? Nếu chương trình phải được liên kết tĩnh trước khi phân phối, giai đoạn liên kết tĩnh có thể nhận ra rằng mặc dù chương trình không có sự mơ hồ trước khi thay đổi Y và Z, nhưng những thay đổi đối với Y và Z đã khiến mọi thứ trở nên mơ hồ và trình liên kết có thể từ chối xây dựng chương trình trừ khi hoặc cho đến khi sự mơ hồ đó được giải quyết. Mặt khác, có thể người có cả W và các phiên bản mới của Y và Z là người chỉ muốn chạy chương trình và không có mã nguồn nào cho nó. Khi W.Test()chạy, nó sẽ không còn rõ ràngW.Test() thì nên làm, nhưng cho đến khi người dùng cố gắng chạy W với phiên bản mới của Y và Z, sẽ không có cách nào bất kỳ bộ phận nào của hệ thống có thể nhận ra có sự cố (trừ khi W được coi là không hợp lệ ngay cả trước khi thay đổi thành Y và Z ).

Kim cương không phải là vấn đề, miễn là bạn không sử dụng bất kỳ thứ gì như thừa kế ảo C ++: trong kế thừa thông thường, mỗi lớp cơ sở giống với một trường thành viên (thực sự chúng được bố trí trong RAM theo cách này), cung cấp cho bạn một số cú pháp và một thêm khả năng ghi đè nhiều phương thức ảo hơn. Điều đó có thể gây ra một số mơ hồ tại thời điểm biên dịch nhưng điều đó thường dễ giải quyết.

Mặt khác, với thừa kế ảo, nó quá dễ dàng vượt quá tầm kiểm soát (và sau đó trở thành một mớ hỗn độn). Hãy coi như một ví dụ về sơ đồ "trái tim":

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

Trong C ++, điều đó là hoàn toàn không thể: ngay sau khi Fvà Gđược hợp nhất thành một lớp, các ký tự của chúng Acũng được hợp nhất, dấu chấm. Điều đó có nghĩa là bạn có thể không bao giờ coi các lớp cơ sở là không rõ ràng trong C ++ (trong ví dụ này, bạn phải xây dựng Atrong Hđó để bạn phải biết rằng nó hiện diện ở đâu đó trong hệ thống phân cấp). Tuy nhiên, trong các ngôn ngữ khác, nó có thể hoạt động; ví dụ, Fvà Gcó thể tuyên bố rõ ràng A là "nội bộ", do đó ngăn cấm việc hợp nhất do hậu quả và làm cho chúng trở nên vững chắc một cách hiệu quả.

Một ví dụ thú vị khác ( không phải C ++ - cụ thể):

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

Ở đây, chỉ Bsử dụng kế thừa ảo. Vì vậy, Echứa hai Bs chia sẻ cùng một A. Bằng cách này, bạn có thể nhận được một A*con trỏ trỏ đến E, nhưng bạn không thể bỏ nó vào một B*con trỏ mặc dù đối tượng là thực sự B như dàn diễn viên như vậy là mơ hồ, và sự mơ hồ này không thể được phát hiện tại thời gian biên dịch (trừ khi trình biên dịch thấy toàn bộ chương trình). Đây là mã kiểm tra:

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;
}

Hơn nữa, việc triển khai có thể rất phức tạp (phụ thuộc vào ngôn ngữ; xem câu trả lời của benjismith).