Tôi đang phát triển ngôn ngữ lập trình của riêng tôi. Đó là ngôn ngữ có mục đích chung (nghĩ rằng Python đã gõ tĩnh cho máy tính để bàn, nghĩa là int x = 1;) không dành cho đám mây.
Bạn có nghĩ rằng không nên cho phép thừa kế hoặc Mixins? (cho rằng người dùng ít nhất sẽ có giao diện)
Ví dụ: Google Go, Một ngôn ngữ hệ thống gây sốc cho cộng đồng lập trình bằng cách không cho phép kế thừa.
Câu trả lời:
Trên thực tế, chúng ta thấy ngày càng nhiều rằng việc sử dụng tính kế thừa là tối ưu phụ bởi vì (trong số những thứ khác) nó dẫn đến khớp nối chặt chẽ.
Kế thừa triển khai luôn có thể được thay thế bằng kế thừa giao diện cộng với thành phần và các thiết kế phần mềm hiện đại hơn có xu hướng đi theo hướng sử dụng kế thừa ngày càng ít hơn, có lợi cho thành phần.
Vì vậy, có , không cung cấp thừa kế nói riêng là một quyết định thiết kế hoàn toàn hợp lệ và rất thịnh hành .
Mixins, mặt khác, thậm chí không (chưa) một tính năng ngôn ngữ chủ đạo, và ngôn ngữ mà ta cung cấp một tính năng gọi là “mixin” thường hiểu những điều rất khác nhau bởi nó. Hãy cung cấp nó, hoặc không. Cá nhân tôi thấy nó rất hữu ích nhưng thực hiện nó có thể rất khó.
Lý do về việc kế thừa (hoặc bất kỳ tính năng đơn lẻ nào, thực sự) có cần thiết hay không mà không xem xét phần còn lại của ngữ nghĩa của ngôn ngữ là vô nghĩa; bạn đang cãi nhau trong chân không
Những gì bạn cần là một triết lý thiết kế ngôn ngữ nhất quán; ngôn ngữ cần có khả năng giải quyết vấn đề một cách tao nhã. Mô hình để đạt được điều này có thể hoặc không cần kế thừa, nhưng thật khó để đánh giá điều này nếu không có bức tranh lớn.
Ví dụ, nếu ngôn ngữ của bạn có các hàm hạng nhất, ứng dụng hàm một phần, kiểu dữ liệu đa hình, biến kiểu và kiểu chung, bạn có khá nhiều cơ sở giống như bạn có với kế thừa OOP cổ điển, nhưng sử dụng mô hình khác.
Nếu bạn có ràng buộc muộn, gõ động, thuộc tính phương thức, đối số hàm linh hoạt và hàm hạng nhất, bạn cũng bao gồm cùng một căn cứ, nhưng một lần nữa, sử dụng mô hình khác.
(Tìm các ví dụ cho hai mô hình được phác thảo là một bài tập cho người đọc.)
Vì vậy, hãy suy nghĩ về loại ngữ nghĩa mà bạn muốn, chơi xung quanh với chúng và xem liệu chúng có đủ mà không cần thừa kế. Nếu họ không, bạn có thể quyết định ném thừa kế vào hỗn hợp, hoặc bạn có thể quyết định rằng thiếu một cái gì đó khác.
Đúng.
Tôi nghĩ rằng không cho phép thừa kế là tốt, đặc biệt nếu ngôn ngữ của bạn được gõ động. Bạn có thể đạt được tái sử dụng mã tương tự bằng cách, ví dụ, ủy quyền hoặc thành phần. Ví dụ, tôi đã viết một số chương trình khá phức tạp - okay, không có phức tạp:) - trong JavaScript mà không cần bất kỳ thừa kế. Về cơ bản tôi đã sử dụng các đối tượng như các cấu trúc dữ liệu đại số với một số hàm được đính kèm như các phương thức. Tôi cũng có một loạt các hàm không phải là phương thức hoạt động trên các đối tượng này.
Nếu bạn có kiểu gõ động - và tôi giả sử bạn làm thế - bạn cũng có thể có đa hình mà không cần kế thừa. Ngoài ra, nếu bạn cho phép thêm các phương thức tùy ý vào các đối tượng trong thời gian chạy, bạn sẽ không thực sự cần những thứ như mixins rất nhiều.
Một tùy chọn khác - mà tôi nghĩ là một lựa chọn tốt - là mô phỏng JavaScript và sử dụng các nguyên mẫu. Đây là đơn giản hơn các lớp học nhưng cũng rất linh hoạt. Chỉ cần một cái gì đó để xem xét.
Vì vậy, tất cả đã nói, tôi sẽ đi cho nó.
Vâng, đó là một quyết định thiết kế hoàn toàn hợp lý để bỏ qua sự kế thừa.
Trong thực tế, có những lý do rất tốt để loại bỏ kế thừa thực hiện, vì nó có thể tạo ra một số mã cực kỳ phức tạp và khó duy trì. Tôi thậm chí còn đi xa hơn khi coi sự kế thừa (vì nó thường được triển khai trong hầu hết các ngôn ngữ OOP) như là một hành vi sai trái.
Clojure, chẳng hạn, không cung cấp sự kế thừa thực hiện, muốn cung cấp một tập hợp các tính năng trực giao (giao thức, dữ liệu, hàm, macro) có thể được sử dụng để đạt được kết quả tương tự nhưng sạch sẽ hơn nhiều.
Đây là một video mà tôi thấy rất ngộ về chủ đề chung này, trong đó Rich Hickey xác định các nguồn phức tạp cơ bản trong các ngôn ngữ lập trình (bao gồm cả kế thừa) và trình bày các lựa chọn thay thế cho mỗi: Đơn giản được thực hiện dễ dàng
Khi tôi lần đầu tiên chạy qua thực tế là các lớp VB6 không hỗ trợ kế thừa (chỉ giao diện), nó thực sự làm tôi khó chịu (và vẫn vậy).
Tuy nhiên, lý do rất tệ là vì nó cũng không có tham số hàm tạo, vì vậy bạn không thể thực hiện phép tiêm phụ thuộc thông thường (DI). Nếu bạn có DI thì điều đó quan trọng hơn kế thừa vì bạn có thể tuân theo nguyên tắc ưu tiên sáng tác hơn thừa kế. Dù sao đó cũng là cách tốt hơn để sử dụng lại mã.
Không có Mixins mặc dù? Nếu bạn muốn thực hiện một giao diện và ủy thác tất cả công việc của giao diện đó cho một đối tượng được đặt thông qua việc tiêm phụ thuộc, thì Mixins là lý tưởng. Nếu không, bạn phải viết tất cả các mã soạn sẵn để ủy quyền mọi phương thức và / hoặc thuộc tính cho đối tượng con. Tôi làm điều đó rất nhiều (nhờ C #) và đó là một điều tôi ước mình không phải làm.
Để không đồng ý với câu trả lời khác: không, bạn bỏ qua các tính năng khi chúng không tương thích với thứ bạn muốn nhiều hơn. Java (và các ngôn ngữ GC'd khác) đã loại bỏ việc quản lý bộ nhớ rõ ràng vì nó muốn loại an toàn hơn. Haskell đã ném ra đột biến vì nó muốn lý luận tương đương và các loại ưa thích hơn. Thậm chí C đã ném ra (hoặc tuyên bố là bất hợp pháp) một số loại răng cưa và hành vi khác vì nó muốn tối ưu hóa trình biên dịch nhiều hơn.
Vì vậy, câu hỏi là: Bạn muốn gì hơn là thừa kế?
free/ deletehoạt động cung cấp cho bạn khả năng vô hiệu hóa các tài liệu tham khảo; trừ khi hệ thống loại của bạn có thể theo dõi tất cả các tài liệu tham khảo bị ảnh hưởng, điều đó làm cho ngôn ngữ không an toàn. Đặc biệt, cả C và C ++ đều không an toàn. Đúng là bạn có thể thỏa hiệp bằng cách này hay cách khác (ví dụ: loại tuyến tính hoặc hạn chế phân bổ) để khiến họ đồng ý. Nói chính xác tôi nên nói rằng Java muốn loại an toàn với một hệ thống loại đơn giản, cụ thể và phân bổ không hạn chế hơn.
nulltham chiếu). Cấm freelà một hạn chế bổ sung khá tùy tiện. Tóm lại, việc một ngôn ngữ là loại an toàn hay không phụ thuộc nhiều vào định nghĩa của bạn về an toàn loại hơn là ngôn ngữ.
Ttham chiếu đều đề cập đến một nullhoặc một đối tượng của một lớp mở rộng T; nulllà xấu, nhưng các hoạt động nullném một ngoại lệ được xác định rõ hơn là làm hỏng loại bất biến ở trên. Tương phản với C ++: sau khi gọi đến delete, một T*con trỏ có thể trỏ đến bộ nhớ không còn giữ Tđối tượng. Tồi tệ hơn, thực hiện một phép gán trường bằng con trỏ đó trong một phép gán, bạn có thể cập nhật hoàn toàn một trường của một đối tượng của một lớp khác nếu nó chỉ được đặt ở một địa chỉ gần đó. Đó không phải là loại an toàn theo bất kỳ định nghĩa hữu ích của thuật ngữ.
Không.
Nếu bạn muốn loại bỏ một tính năng ngôn ngữ cơ bản, thì bạn đang tuyên bố rằng nó không bao giờ, không bao giờ cần thiết (hoặc không chính đáng để thực hiện, không áp dụng ở đây). Và "không bao giờ" là một từ mạnh mẽ trong công nghệ phần mềm. Bạn sẽ cần một lời biện minh rất mạnh mẽ để đưa ra tuyên bố như vậy.
Phát biểu từ quan điểm C ++ nghiêm ngặt, kế thừa rất hữu ích cho hai mục đích chính:
Đối với điểm 1 miễn là bạn có một số cách để chia sẻ mã mà không phải thưởng thức quá nhiều màn nhào lộn, bạn có thể loại bỏ tính kế thừa. Đối với điểm 2. Bạn có thể đi theo cách java và nhấn mạnh vào một giao diện để thực hiện tính năng này.
Lợi ích của việc loại bỏ thừa kế là
Sự đánh đổi chủ yếu là giữa "Đừng lặp lại chính mình" và Linh hoạt ở một bên và tránh vấn đề ở phía bên kia. Cá nhân tôi rất ghét thấy sự kế thừa đi từ C ++ đơn giản vì một số nhà phát triển khác có thể không đủ thông minh để thấy trước các vấn đề.
Bạn có nghĩ rằng không nên cho phép thừa kế hoặc Mixins? (cho rằng người dùng ít nhất sẽ có giao diện)
Bạn có thể thực hiện rất nhiều công việc rất hữu ích mà không cần thực hiện kế thừa hoặc mixins, nhưng tôi tự hỏi liệu bạn có nên có một kiểu kế thừa giao diện nào đó không, tức là một tuyên bố cho biết nếu một đối tượng thực hiện giao diện A thì nó cũng cần giao diện B (nghĩa là A là một chuyên ngành của B và do đó có một mối quan hệ loại). Mặt khác, đối tượng kết quả của bạn chỉ cần ghi lại rằng nó thực hiện cả hai giao diện, do đó không có quá nhiều phức tạp ở đó. Tất cả hoàn toàn có thể làm được.
Việc thiếu kế thừa triển khai có một nhược điểm rõ ràng: bạn sẽ không thể xây dựng các vtables được lập chỉ mục số cho các lớp của mình và do đó sẽ phải thực hiện tra cứu băm cho mỗi lệnh gọi phương thức (hoặc tìm ra một cách thông minh để tránh chúng). Điều này có thể gây đau đớn nếu bạn định tuyến ngay cả các giá trị cơ bản (ví dụ: số) thông qua cơ chế này. Ngay cả một triển khai băm rất tốt cũng có thể tốn kém khi bạn nhấn nó nhiều lần trong mỗi vòng lặp bên trong!