Có ngôn ngữ OO nào không có sự kế thừa không?

Trong buổi đánh giá mã ngày hôm nay, một đồng nghiệp của tôi đã nói một điều thú vị:

prototypechỉ hữu ích khi bạn cần thừa kế - và khi nào thì thừa kế bao giờ là một ý tưởng tốt ?

Tôi đã nghĩ về điều này và tôi nhận ra rằng tôi thường sử dụng tính kế thừa để đi vòng quanh mã được thiết kế tồi ngay từ đầu. Phong cách OO hiện đại thích sáng tác hơn sự kế thừa, nhưng tôi không biết bất kỳ ngôn ngữ nào đã làm điều này thành trái tim và thực sự thi hành nó.

Có bất kỳ ngôn ngữ lập trình đa mục đích nào với các lớp, đối tượng, phương thức, giao diện, v.v., không cho phép kế thừa dựa trên lớp không? (Nếu một ý tưởng như vậy không có ý nghĩa, tại sao không?)

Đặt sang một bên câu hỏi về định nghĩa lập trình hướng đối tượng , câu hỏi trở thành một trong những "ngôn ngữ chỉ sử dụng thành phần và không có công cụ để kế thừa?"

Câu trả lời cho điều này khá đơn giản là "có". Trong khi đó, không có cách nào để làm thừa kế như người ta nghĩ về nó. Người ta có thể nhúng một đối tượng trong một đối tượng khác và mở rộng đối tượng đó. Từ đối tượng Desoriented Language ( github mirror ):

type Person struct {
        Name string
}

func (p *Person) Intro() string {
        return p.Name
}

type Woman struct {
        Person
}

func (w *Woman) Intro() string {
        return "Mrs. " + w.Person.Intro()
}

Bạn đã có một cấu trúc người có Tên là Chuỗi. Nó có một chức năng công khai gọi là Intro trả về tên. Cấu trúc Woman cũng có một chức năng cho Giới thiệu truy cập thanh chống được nhúng trong nó. Và do đó, người ta có thể thực hiện ý định thừa kế bằng cách chỉ sử dụng thành phần.

Thông tin thêm về điều này có thể được nhìn thấy tại Hướng dẫn của GoLang: Kế thừa và phân lớp trong Go - hoặc gần giống với nó .

Vì vậy, có, có thể có một ngôn ngữ OO mà không cần kế thừa, và một ngôn ngữ tồn tại.

Bên trong, điều này được gọi là nhúng và cung cấp cho các cấu trúc kèm theo khả năng truy cập các trường và chức năng nhúng như thể nó cũng có chúng - nhưng nó không phải là một lớp con. Triết lý thiết kế có thể được tìm thấy trong Câu hỏi thường gặp về Go: Tại sao không có kiểu thừa kế?

Có bất kỳ ngôn ngữ lập trình đa mục đích nào với các lớp, đối tượng, phương thức, giao diện, v.v., không cho phép kế thừa dựa trên lớp không?

Điều này đọc rất giống với mô tả về VBA - Visual Basic cho Ứng dụng, được nhúng trong Microsoft Office và các máy chủ hỗ trợ VBA khác (ví dụ: AutoCAD, Sage 300 ERP, v.v.) hoặc thậm chí VB6. "A" của "Cơ bản" là viết tắt của "Tất cả mục đích", vì vậy có phần "mục đích chung".

VB6 / VBA có các lớp (và do đó là các đối tượng), các phương thức và giao diện - bạn có thể định nghĩa một ISomethinggiao diện trong một mô-đun lớp như thế này:

Option Explicit

Public Sub DoSomething()
End Sub

Và sau đó có một lớp khác thực hiện điều này:

Option Explicit
Implements ISomething

Private Sub ISomething_DoSomething()
    'implementation here
End Sub

Một lớp như vậy, không có thành viên nào, chỉ có thể được truy cập qua ISomethinggiao diện của nó - và rất có thể có hàng tá các triển khai khác nhau ISomethingngoài đó, vì vậy mã OOP VBA hoàn toàn có khả năng đa hình, và nó hoàn toàn hợp pháp cho một lớp nhất định để thực hiện nhiều giao diện, quá.

Tuy nhiên, VB6 / VBA không cho phép kế thừa lớp , do đó bạn không thể kế thừa triển khai từ loại khác, chỉ giao diện của nó. Bây giờ, cho dù đây là một tai nạn, một lỗi thiết kế, đột quỵ của thiên tài hay một sự giám sát xấu xí khổng lồ đang mở ra cho cuộc tranh luận; Không rõ liệu VB6 / VBA có làm được điều này hay không , nhưng chắc chắn nó sẽ thực thi nó.

Nếu Go không thực hiện kế thừa lớp và dù sao cũng là ngôn ngữ OOP , thì tôi không hiểu tại sao VB6 / VBA cũng không thể được coi là ngôn ngữ OOP.</PreemptiveResponseToVBAHatersThatWillSayItIsNotAnOOPLanguage>

Bạn có thể làm cho trình biên dịch thực thi kế thừa chọn lọc thông qua việc sử dụng riêng tư / được bảo vệ và thông qua việc sử dụng các kỹ thuật "PImpl" hoặc "Thực hiện riêng tư" hiện đại.

Nhiều API chỉ hiển thị những thành phần mà bạn muốn người dùng kế thừa và ẩn phần còn lại trong một lớp triển khai riêng. Vì vậy, bạn có thể viết các lớp có giao diện công khai, trên thực tế, không thể quản lý được, chỉ có thể sử dụng thông qua thành phần đối tượng và trình biên dịch được thi hành. Điều này thường là thực hành tốt, khi nó sử dụng trình biên dịch để thực thi ý định của phần mềm.

Tìm kiếm nhanh các chức năng thành viên riêng tư trong javascript cho thấy có một nguyên tắc tương tự, mặc dù bất kỳ ai cũng có thể thấy mã của bạn nếu họ có thể sử dụng nó: http://www.crockford.com/javascript/private.html