Chúng ta có thể thay thế hoàn toàn kế thừa bằng cách sử dụng mô hình chiến lược và tiêm phụ thuộc không?

Ví dụ:

var duckBehaviors = new Duckbehavior();
duckBehaviors.quackBehavior = new Quack();
duckBehaviors.flyBehavior = new FlyWithWings();
Duck mallardDuck = new Duck(DuckTypes.MallardDuck, duckBehaviors)

Vì lớp Duck chứa tất cả các hành vi (trừu tượng), việc tạo một lớp mới MallardDuck(mở rộng Duck) dường như không bắt buộc.

Tham khảo: Mẫu thiết kế đầu tiên, Chương 1.

Chắc chắn, nhưng chúng tôi gọi đó là thành phần và đoàn . Mô hình chiến lược và tiêm phụ thuộc có thể có cấu trúc tương tự nhau nhưng ý định của chúng là khác nhau.

Mẫu chiến lược cho phép sửa đổi thời gian chạy của hành vi trong cùng một giao diện. Tôi có thể bảo một con vịt trời biết bay và xem nó bay bằng đôi cánh. Sau đó đổi nó lấy một con vịt phi công phản lực và xem nó bay với các hãng hàng không Delta. Làm điều đó trong khi chương trình đang chạy là một điều Chiến lược mẫu.

Dependency Injection là một kỹ thuật để tránh phụ thuộc mã hóa cứng để họ có thể thay đổi độc lập mà không yêu cầu khách hàng phải sửa đổi khi họ thay đổi. Khách hàng chỉ đơn giản là bày tỏ nhu cầu của họ mà không biết họ sẽ được đáp ứng như thế nào. Do đó, làm thế nào chúng được đáp ứng được quyết định ở nơi khác (thường là chính). Bạn không cần hai con vịt để sử dụng kỹ thuật này. Chỉ cần một cái gì đó sử dụng một con vịt mà không biết hoặc quan tâm con vịt nào. Một cái gì đó không xây dựng con vịt hoặc đi tìm nó nhưng hoàn toàn hạnh phúc khi sử dụng bất cứ con vịt nào bạn đưa nó.

Nếu tôi có một lớp vịt cụ thể, tôi có thể cho nó thực hiện hành vi bay. Tôi thậm chí có thể khiến nó chuyển đổi các hành vi từ fly-with-wing sang fly-with-Delta dựa trên một biến trạng thái. Biến mà có thể là một boolean, một int, hoặc nó có thể là một FlyBehaviormà có một flyphương pháp mà không bất cứ phong cách bay mà không có tôi phải thử nghiệm nó với một nếu. Bây giờ tôi có thể thay đổi kiểu bay mà không cần thay đổi loại vịt. Bây giờ Mallards có thể trở thành phi công. Đây là thành phần và đoàn . Con vịt bao gồm một FlyBehavior và nó có thể ủy thác các yêu cầu bay cho nó. Bạn có thể thay thế tất cả các hành vi vịt của bạn cùng một lúc theo cách này hoặc giữ một cái gì đó cho mỗi hành vi hoặc bất kỳ sự kết hợp nào ở giữa.

Điều này cung cấp cho bạn tất cả các quyền hạn mà thừa kế có ngoại trừ một. Kế thừa cho phép bạn thể hiện phương thức Vịt nào bạn ghi đè trong các kiểu con Vịt. Thành phần và ủy quyền yêu cầu Vịt phải ủy quyền rõ ràng cho các kiểu con ngay từ đầu. Điều này linh hoạt hơn nhiều nhưng nó liên quan đến việc gõ bàn phím nhiều hơn và Duck phải biết điều đó đang xảy ra.

Tuy nhiên, nhiều người tin rằng sự kế thừa phải được thiết kế rõ ràng ngay từ đầu. Và nếu không, bạn nên đánh dấu các lớp của mình là niêm phong / cuối cùng để không cho phép thừa kế. Nếu bạn có quan điểm đó thì sự kế thừa thực sự không có lợi thế hơn so với thành phần và sự ủy nhiệm. Bởi vì sau đó, dù bằng cách nào bạn cũng phải thiết kế để mở rộng ngay từ đầu hoặc sẵn sàng xé mọi thứ sau này.

Xé mọi thứ thực sự là một lựa chọn phổ biến. Chỉ cần lưu ý rằng có những trường hợp đó là một vấn đề. Nếu bạn đã triển khai độc lập các thư viện hoặc mô-đun mã mà bạn không có ý định cập nhật với bản phát hành tiếp theo, bạn có thể sẽ gặp khó khăn khi xử lý các phiên bản của các lớp không biết gì về những gì bạn sắp làm.

Mặc dù sẵn sàng xé mọi thứ sau này có thể giải phóng bạn khỏi việc thiết kế, có một điều rất mạnh mẽ về việc có thể thiết kế một cái gì đó sử dụng một con vịt mà không cần phải biết con vịt sẽ thực sự làm gì khi sử dụng. Điều đó không biết là công cụ mạnh mẽ. Nó cho phép bạn ngừng suy nghĩ về vịt trong một thời gian và suy nghĩ về phần còn lại của mã của bạn.

"Chúng ta có thể" và "chúng ta nên" là những câu hỏi khác nhau. Thành phần ủng hộ thừa kế không nói không bao giờ sử dụng thừa kế. Vẫn có những trường hợp thừa kế có ý nghĩa nhất. Tôi sẽ chỉ cho bạn ví dụ yêu thích của tôi :

public class LoginFailure : System.ApplicationException {}

Kế thừa cho phép bạn tạo các ngoại lệ với các tên mô tả cụ thể hơn chỉ trong một dòng.

Hãy thử làm điều đó với thành phần và bạn sẽ nhận được một mớ hỗn độn. Ngoài ra, không có rủi ro về vấn đề thừa kế yo-yo vì không có dữ liệu hoặc phương pháp nào ở đây để tái sử dụng và khuyến khích chuỗi kế thừa. Tất cả điều này thêm là một tên tốt. Đừng bao giờ đánh giá thấp giá trị của một cái tên hay.

Bạn có thể thay thế hầu hết mọi phương pháp bằng bất kỳ phương pháp nào khác và vẫn sản xuất phần mềm hoạt động. Tuy nhiên, một số phù hợp hơn với một vấn đề cụ thể hơn những vấn đề khác.

Nó phụ thuộc vào rất nhiều thứ mà người ta thích hơn. Ưu tiên nghệ thuật trong ứng dụng, kinh nghiệm trong nhóm, dự kiến ​​phát triển trong tương lai, sở thích cá nhân và người mới sẽ khó khăn như thế nào để có được cái đầu của mình xung quanh nó, kể tên một vài người.

Khi bạn có nhiều kinh nghiệm hơn và đấu tranh thường xuyên hơn với những sáng tạo của người khác, bạn có thể sẽ nhấn mạnh hơn vào sự suy ngẫm cuối cùng.

Kế thừa vẫn là một công cụ mô hình hóa hợp lệ và mạnh mẽ không nhất thiết phải luôn linh hoạt nhất nhưng nó cung cấp hướng dẫn mạnh mẽ cho những người mới có thể biết ơn về ánh xạ rõ ràng đến miền vấn đề.

Kế thừa không quan trọng như đã từng nghĩ. Nó vẫn còn quan trọng , và loại bỏ nó sẽ là một sai lầm tồi tệ.

Một ví dụ cực đoan là Objective-C trong đó mọi thứ là một lớp con của NSObject (trình biên dịch thực sự không cho phép bạn khai báo một lớp không có lớp cơ sở, vì vậy mọi thứ không được tích hợp trong trình biên dịch phải là lớp con của một thứ gì đó tích hợp vào trình biên dịch). Có rất nhiều nội dung hữu ích được tích hợp trong NSObject mà bạn sẽ không phải bỏ lỡ.

Một ví dụ thú vị khác là UIView, lớp "xem" cơ bản trong phát triển UIKit cho iOS. Đây là một lớp giống như một chức năng khai báo lớp trừu tượng mà các lớp con được cho là phải điền vào, nhưng bản thân nó cũng hữu ích. Nó có các lớp con được cung cấp bởi UIKit, thường được sử dụng như là. Có thành phần của nhà phát triển cài đặt các cuộc phỏng vấn trong một khung nhìn. Và thường có các lớp con do nhà phát triển định nghĩa, thường sử dụng thành phần. Không có quy tắc duy nhất nghiêm ngặt hoặc thậm chí quy tắc, bạn sử dụng bất cứ điều gì phù hợp với yêu cầu của bạn tốt nhất.

[Tôi sẽ mạo hiểm một câu trả lời táo tợn cho câu hỏi giật gân.]

Chúng ta có thể thay thế hoàn toàn kế thừa bằng cách sử dụng mô hình chiến lược và tiêm phụ thuộc không?

Có ... ngoại trừ mẫu chiến lược tự sử dụng tính kế thừa. Mẫu chiến lược hoạt động trên kế thừa giao diện. Thay thế sự kế thừa bằng thành phần + chiến lược di chuyển sự kế thừa đến một nơi khác. Tuy nhiên, thay thế như vậy thường là đáng làm, bởi vì nó cho phép trêu chọc các thứ bậc khác nhau .

Không. Nếu một con vịt trời yêu cầu các thông số khác nhau để khởi tạo so với một số loại vịt khác, thì đó sẽ là một cơn ác mộng khi thay đổi. Ngoài ra, bạn có thể khởi tạo một con vịt? Đó là nhiều hơn một con vịt trời hoặc vịt tiếng Quan thoại hoặc bất kỳ loại vịt nào bạn có.

Ngoài ra tôi có thể muốn một số logic xung quanh các loại để phân cấp loại có thể tốt hơn.

Bây giờ nếu việc tái sử dụng mã trở nên có vấn đề đối với một số chức năng, chúng ta có thể soạn thảo nó bằng cách chuyển các hàm qua hàm tạo.

Một lần nữa, nó thực sự phụ thuộc vào trường hợp sử dụng của bạn. Nếu bạn chỉ có một con vịt và một con vịt trời, một hệ thống phân cấp lớp là một giải pháp đơn giản hơn nhiều.

Nhưng đây là một ví dụ mà bạn muốn sử dụng mẫu chiến lược: Nếu bạn có các lớp khách hàng và bạn muốn chuyển qua một chiến lược thanh toán (giao diện) có thể là chiến lược thanh toán theo giờ hạnh phúc hoặc chiến lược thanh toán thông thường, bạn có thể vượt qua nó trong hàm tạo. Bằng cách này, bạn không phải tạo hai lớp khách hàng khác nhau và bạn không cần phân cấp. Bạn chỉ có một lớp khách hàng.