Có thành phần nào không thể thực hiện được thừa kế đó không?

Question

Thành phần và kế thừa.

Tôi biết rằng cả hai công cụ đều được chọn khi thích hợp và bối cảnh rất quan trọng trong việc lựa chọn giữa bố cục và kế thừa. Tuy nhiên, các cuộc thảo luận về bối cảnh thích hợp cho mỗi thường là một chút mờ; điều này khiến tôi bắt đầu xem xét cách thức thừa kế và đa hình rõ ràng là những khía cạnh riêng biệt của OOP truyền thống.

Đa hình cho phép người ta chỉ định mối quan hệ "là-a" như nhau cũng như thừa kế. Đặc biệt, kế thừa từ một lớp cơ sở ngầm tạo ra một mối quan hệ đa hình giữa lớp đó và các lớp con của nó. Tuy nhiên, trong khi đa hình có thể được thực hiện bằng cách sử dụng giao diện thuần túy, thừa kế làm phức tạp mối quan hệ đa hình bằng cách đồng thời chuyển các chi tiết thực hiện. Bằng cách này, thừa kế khá khác biệt với tính đa hình thuần túy.

Là một công cụ, thừa kế phục vụ các lập trình viên khác biệt so với đa hình (thông qua giao diện tinh khiết) bằng cách đơn giản hóa việc thực hiện tái sử dụng trong trường hợp tầm thường. Tuy nhiên, trong phần lớn các trường hợp, các chi tiết thực hiện của một siêu lớp phụ xung đột một cách tinh tế với các yêu cầu của một lớp con. Đây là lý do tại sao chúng tôi có "ghi đè" và "ẩn thành viên". Trong những trường hợp này, việc tái sử dụng được cung cấp bởi thừa kế được mua với nỗ lực bổ sung của việc xác minh các thay đổi trạng thái và các đường dẫn thực hiện qua các cấp mã: các chi tiết thực hiện "phẳng" hoàn chỉnh của lớp con được trải ra giữa nhiều lớp, thường có nghĩa là nhiều tệp, trong đó chỉ có các phần áp dụng cho lớp con đang được đề cập đến. Nhìn qua hệ thống phân cấp đó là hoàn toàn cần thiết khi giao dịch với thừa kế, bởi vì không nhìn vào mã của siêu lớp, không có cách nào để biết những chi tiết không được ghi đè nào đang làm khỉ với trạng thái của bạn hoặc chuyển hướng thực hiện của bạn.

Để so sánh, việc sử dụng độc quyền bố cục đảm bảo bạn sẽ thấy trạng thái nào có thể được sửa đổi bởi các đối tượng được hiển thị rõ ràng có phương thức được gọi theo ý của bạn. Việc triển khai thực hiện phẳng vẫn chưa đạt được (và thậm chí không thực sự mong muốn, vì lợi ích của lập trình có cấu trúc là đóng gói và trừu tượng hóa các chi tiết triển khai) nhưng bạn vẫn nhận được mã tái sử dụng, và bạn sẽ chỉ phải tìm ở một nơi khi mã lỗi.

Với mục tiêu thử nghiệm những ý tưởng này trong thực tế, tránh thừa kế truyền thống cho một sự kết hợp của tính đa hình giao diện dựa trên tinh khiết và thành phần đối tượng, tôi tự hỏi,

Có thành phần đối tượng bất cứ điều gì và giao diện không thể thực hiện điều đó thừa kế có thể ?

Sửa

Trong các câu trả lời cho đến nay, ewernli tin không có những kỳ công kỹ thuật sẵn sàng cho một kỹ thuật nhưng không phải là khác; sau đó, ông đề cập đến cách thức các mô hình và phương pháp tiếp cận thiết kế khác nhau vốn có đối với từng kỹ thuật. Điều này là lý do. Tuy nhiên, gợi ý này khiến tôi phải tinh chỉnh câu hỏi của mình bằng cách hỏi liệu việc sử dụng độc quyền các thành phần và giao diện thay cho thừa kế truyền thống có ngăn cấm việc sử dụng bất kỳ mẫu thiết kế chính nào không? Và nếu vậy, không có các mẫu tương đương để sử dụng trong tình huống của tôi?

Answer 1

Về mặt kỹ thuật, mọi thứ có thể được thực hiện với thừa kế cũng có thể được thực hiện với ủy quyền. Vì vậy, câu trả lời sẽ là "không".

Chuyển đổi thừa kế vào đoàn

Hãy nói rằng chúng tôi có các lớp sau đây thực hiện với thừa kế:

public class A { 
    String a = "A"; 
    void doSomething() { .... } 
    void getDisplayName() { return a } 
    void printName { System.out.println(this.getDisplayName() }; 
} 

public class B extends A { 
    String b = "B"; 
    void getDisplayName() { return a + " " + b; } 
    void doSomething() { super.doSomething() ; ... }  
} 

Các công cụ hoạt động độc đáo, và kêu gọi printName trên một thể hiện của B sẽ in "A B" trong giao diện điều khiển.

Bây giờ, nếu chúng ta viết lại rằng với phái đoàn, chúng tôi nhận được:

public class A { 
    String a = "A"; 
    void doSomething() { .... } 
    void getDisplayName() { return a } 
    void printName { System.out.println(this.getName() }; 
} 

public class B { 
    String b = "B"; 
    A delegate = new A(); 
    void getDisplayName() { return delegate.a + " " + b; } 
    void doSomething() { delegate.doSomething() ; ... } 
    void printName() { delegate.printName() ; ... } 
} 

Chúng ta cần phải xác định printName trong B và cũng để tạo ra các đại biểu khi B được khởi tạo. Một cuộc gọi đến doSomething sẽ hoạt động theo cách tương tự như với kế thừa. Nhưng một cuộc gọi đến printName sẽ in "A" trong bảng điều khiển. Thật vậy với đoàn đại biểu, chúng tôi đã mất khái niệm mạnh mẽ về "điều này" đang bị ràng buộc đối tượng dụ và các phương thức cơ bản có thể gọi các phương thức đã được ghi đè.

Điều này có thể được giải quyết bằng ngôn ngữ hỗ trợ phái đoàn thuần túy. Với đoàn đại biểu thuần túy, "điều này" trong đại biểu sẽ vẫn tham chiếu trường hợp B. Điều đó có nghĩa là this.getName() sẽ bắt đầu gửi phương thức từ lớp B. Chúng tôi đạt được điều tương tự như với thừa kế. Đây là cơ chế được sử dụng trong ngôn ngữ prototype-based chẳng hạn như Self có ủy quyền có tính năng tích hợp sẵn (Bạn có thể đọc here cách thức hoạt động của kế thừa trong Tự).

Nhưng Java không có ủy quyền thuần túy. Khi nào thì bị kẹt? Không thực sự, chúng tôi vẫn có thể làm được điều đó chúng ta có một số nỗ lực nhiều hơn:

public class A implements AInterface { 
    String a = "A"; 
    AInterface owner; // replace "this" 
    A (AInterface o) { owner = o } 
    void doSomething() { .... } 
    void getDisplayName() { return a } 
    void printName { System.out.println(owner.getName() }; 
} 

public class B implements AInterface { 
    String b = "B"; 
    A delegate = new A(this); 
    void getDisplayName() { return delegate.a + " " + b; } 
    void doSomething() { delegate.doSomething() ; ... } 
    void printName() { delegate.printName() ; ... } 
} 

Chúng tôi về cơ bản lại thực hiện những gì được xây dựng trong thừa kế cung cấp. Nó có ý nghĩa không? Không thực sự. Nhưng nó minh họa rằng thừa kế luôn có thể được chuyển đổi thành phái đoàn.

Thảo luận

thừa kế được đặc trưng bởi thực tế là một lớp cơ sở có thể gọi một phương thức được ghi đè trong một lớp học phụ. Đây là ví dụ bản chất của template pattern. Những điều như vậy không thể được thực hiện dễ dàng với phái đoàn. Mặt khác, đây chính là điều khiến cho thừa kế khó sử dụng. Nó đòi hỏi một bước ngoặt về tinh thần để hiểu được nơi công văn đa hình xảy ra và hiệu quả là gì nếu các phương thức bị ghi đè.

Có một số cạm bẫy đã biết về di sản và sự mong manh mong manh nó có thể giới thiệu trong thiết kế. Đặc biệt nếu hệ thống phân cấp lớp phát triển. Cũng có thể có một số vấn đề với equality trong hashCode và equals nếu kế thừa được sử dụng. Nhưng mặt khác, nó vẫn là một cách rất thanh lịch để giải quyết một số vấn đề.

Ngoài ra, ngay cả khi thừa kế có thể được thay thế bằng đoàn, một bạn có thể tranh luận rằng họ vẫn đạt được mục đích khác nhau và bổ sung cho nhau - họ không truyền đạt cùng ý mà không bị bắt bởi tinh khiết kỹ thuật tương đương.

(Lý thuyết của tôi là khi ai đó bắt đầu thực hiện OO, chúng tôi bị cám dỗ để sử dụng quá mức thừa kế vì nó cảm nhận như một tính năng của ngôn ngữ.Sau đó, chúng tôi tìm hiểu đoàn đại biểu đó là mô hình/cách tiếp cận và chúng tôi học cách thích nó là tốt. Sau một thời gian, chúng tôi tìm thấy một sự cân bằng giữa cả hai và phát triển ý thức trực giác của cái nào tốt hơn trong trường hợp đó. Vâng, như bạn thấy, tôi vẫn thích cả hai, và cả hai xứng đáng một số thận trọng trước khi được giới thiệu.)

Một số tài liệu

• Delegation is inheritance

Thừa kế và phái đoàn là các phương thức thay thế cho định nghĩa và chia sẻ gia tăng . Nó có thường được tin rằng phái đoàn cung cấp một mô hình mạnh mẽ hơn. Giấy này chứng minh rằng có một mô hình thừa kế "tự nhiên" " ghi lại tất cả các thuộc tính của số ủy quyền. Độc lập, một số ràng buộc nhất định về khả năng của ủy quyền ghi lại di sản được hiển thị . Cuối cùng, một khung công tác mới hoàn toàn chụp cả hai phái đoàn và thừa kế được phác thảo, và một số của các nhánh của mô hình lai này được khám phá.

• On the notion of inheritance

Một trong những vấn đề nhất-khái niệm hấp dẫn và hầu hết cùng lúc trong lập trình hướng đối tượng là thừa kế. Thừa kế thường là được coi là tính năng mà phân biệt đối tượng theo định hướng lập trình từ các mô hình lập trình hiện đại khác, nhưng các nhà nghiên cứu hiếm khi đồng ý về ý nghĩa và cách sử dụng của nó. [...]

• Systematically refactoring inheritance to delegation in java

Bởi vì các khớp nối mạnh mẽ của các tầng lớp và sự gia tăng của các thành viên lớp không cần thiết gây ra bởi thừa kế, những gợi ý để sử dụng thành phần và đoàn đại biểu thay vì có trở nên phổ biến. Việc trình bày một phép tái cấu trúc tương ứng trong tài liệu có thể dẫn người ta tin rằng sự biến đổi như vậy là một việc thực hiện đơn giản. [...]

Answer 2

Thành phần không thể vít lên cuộc sống cũng như thừa kế, khi các lập trình viên súng nhanh chóng cố gắng giải quyết vấn đề bằng cách thêm các phương pháp và mở rộng hệ thống phân cấp (chứ không phải đưa ra một ý nghĩ để phân cấp tự nhiên)

Thành phần không thể kết quả là kim cương lạ, khiến các đội bảo dưỡng đốt cháy dầu đêm gãi đầu

Thừa kế là bản chất của thảo luận trong các mẫu thiết kế GOF mà sẽ không giống nhau nếu các lập trình viên sử dụng Thành phần ngay từ đầu.

Answer 3

Xem xét bộ công cụ gui.

Điều khiển chỉnh sửa là cửa sổ, nó sẽ kế thừa các chức năng đóng/bật/sơn của cửa sổ - nó không chứa cửa sổ. Sau đó, một điều khiển văn bản phong phú nên chứa các điều khiển chỉnh sửa lưu/đọc/cắt/dán chức năng nó sẽ rất khó sử dụng nếu nó chỉ chứa một cửa sổ và một điều khiển chỉnh sửa.

Answer 4

Tôi có thể sai về điều này, nhưng tôi sẽ nói điều đó, và nếu có ai đó có lý do tôi sai, vui lòng chỉ trả lời nhận xét và không bỏ phiếu cho tôi. Có 1 tình huống tôi có thể nghĩ về nơi thừa kế sẽ vượt trội so với sáng tác.

Giả sử tôi có một thư viện Widget nguồn đóng Tôi đang sử dụng trong một dự án (có nghĩa là các chi tiết thực hiện là một bí ẩn đối với tôi bên cạnh những gì được ghi lại). Bây giờ giả sử mỗi widget có khả năng thêm các widget con. Với sự kế thừa, tôi có thể mở rộng lớp Widget để tạo ra một CustomWidget, và sau đó thêm CustomWidget làm tiện ích con của bất kỳ tiện ích con nào khác trong thư viện. Sau đó, mã của tôi để thêm CustomWidget sẽ trông giống như sau:

Widget baseWidget = new Widget(); 
CustomWidget customWidget = new CustomWidget(); 
baseWidget.addChildWidget(customWidget); 

Rất sạch sẽ và tuân thủ các quy ước của thư viện để thêm tiện ích con. Tuy nhiên, với thành phần, nó sẽ phải là cái gì đó như thế này:

Widget baseWidget = new Widget(); 
CustomWidget customWidget = new CustomWidget(); 
customWidget.addAsChildToWidget(baseWidget); 

Không như sạch sẽ, và cũng có thể phá vỡ những quy ước của thư viện

Bây giờ tôi không nói rằng bạn không thể thực hiện điều này với bố cục (trên thực tế ví dụ của tôi cho thấy bạn rất rõ ràng có thể), nó không chỉ lý tưởng trong mọi hoàn cảnh, và có thể dẫn đến phá vỡ các quy ước và các giải pháp thay thế trực quan không hấp dẫn khác.

Answer 5

Có. Nó là Run Time Type Identification (RTTI).