Lợi ích của OOP cổ điển so với ngôn ngữ giống như Go

Tôi đã suy nghĩ rất nhiều về thiết kế ngôn ngữ và những yếu tố nào cần thiết cho một ngôn ngữ lập trình "lý tưởng" và việc nghiên cứu Google Go đã khiến tôi đặt câu hỏi về nhiều kiến ​​thức phổ biến khác.

Cụ thể, Go dường như có tất cả những lợi ích thú vị từ lập trình hướng đối tượng mà không thực sự có bất kỳ cấu trúc nào của ngôn ngữ hướng đối tượng. Không có lớp học, chỉ có cấu trúc; không có sự kế thừa lớp / cấu trúc - chỉ nhúng cấu trúc. Không có bất kỳ hệ thống phân cấp, không có lớp cha, không có triển khai giao diện rõ ràng. Thay vào đó, quy tắc truyền kiểu dựa trên một hệ thống lỏng lẻo tương tự như gõ vịt, sao cho nếu một cấu trúc thực hiện các yếu tố cần thiết của "Trình đọc" hoặc "Yêu cầu" hoặc "Mã hóa", thì bạn có thể truyền và sử dụng nó như một.

Có điều gì đó về OOP được triển khai trong C ++ và Java và C # vốn có khả năng cao hơn, dễ bảo trì hơn, bằng cách nào đó mạnh mẽ hơn mà bạn phải từ bỏ khi chuyển sang ngôn ngữ như Go? Bạn có lợi ích gì khi từ bỏ để đạt được sự đơn giản mà mô hình mới này đại diện?

EDIT đã
xóa câu hỏi "lỗi thời" mà độc giả dường như bị treo quá mức và tức giận.

Câu hỏi đặt ra là, mô hình hướng đối tượng truyền thống (với hệ thống phân cấp và như vậy) như thường thấy trong các triển khai ngôn ngữ thông thường phải đưa ra điều gì mà không thể thực hiện dễ dàng trong mô hình đơn giản này? Hay nói cách khác, nếu bạn định thiết kế một ngôn ngữ ngày nay, có lý do gì bạn muốn đưa vào khái niệm phân cấp lớp không?

Không có mô hình mới. Hướng đối tượng là một mẫu bạn sử dụng để viết chương trình, thậm chí không được xác định rõ ràng. Các ngôn ngữ khác nhau cung cấp các đặc điểm khác nhau điển hình cho định hướng đối tượng (định nghĩa về các loại mới, đóng gói, phân cấp loại, đa hình, truyền thông điệp và nhiều hơn nữa) nhưng có thể không cung cấp cho người khác. Trong những trường hợp đó, các lập trình viên phải thi đua với họ nếu có nhu cầu.

Nhiều ngôn ngữ cung cấp các tính năng này không có khái niệm tương tự về khái niệm lớp - ví dụ Javascript và Common Lisp. Việc triển khai được cung cấp bởi các ngôn ngữ giống như Java (dựa trên lớp, với sự kế thừa duy nhất, giao diện, công văn dựa trên kiểu) chỉ là một trong những khả năng và không nhất thiết là cách tốt nhất.

Bạn có lợi ích gì khi từ bỏ để đạt được sự đơn giản mà mô hình mới này đại diện?

Việc kiểm tra kiểu cho một hệ thống kiểu cấu trúc phức tạp hơn nhiều so với việc kiểm tra đơn giản nếu lớp cơ sở có trong danh sách thừa kế của bạn hay không. Công văn ảo trở nên phức tạp hơn một chút và có khả năng hoạt động kém hơn.

Liệu một hệ thống như vậy đã lỗi thời khái niệm OOP?

Không. Miễn là bạn có thể tạo chương trình theo 'đối tượng thực hiện công việc' thay vì danh sách hướng dẫn hoặc bộ quy tắc được khai báo hoặc chuỗi chức năng xếp tầng ... việc triển khai không thành vấn đề. Tương tự như vậy, việc thay đổi hệ thống loại không làm mất hiệu lực của bất kỳ nguyên tắc OO phổ biến nào.

Bạn vẫn có thể làm việc trên một loại cơ sở và không quan tâm đến loại thực tế của nó. Bạn vẫn có thể mở rộng các loại mà không sửa đổi chúng. Bạn vẫn có thể làm cho một loại chỉ làm một điều. Bạn vẫn có thể cung cấp giao diện hạt mịn. Bạn vẫn có thể cung cấp trừu tượng cho các loại của bạn.

Làm thế nào một ngôn ngữ cho phép điều đó không thực sự quan trọng.

Tôi nghĩ rằng ý tưởng của bạn về OOP là khá ít:

Tôi đã phát minh ra thuật ngữ 'Lập trình hướng đối tượng' và {Java và C ++} này không phải là điều tôi nghĩ.
- Alan Kay .

Sự lựa chọn gõ (phân nhóm chỉ định, phân nhóm cấu trúc hoặc gõ vịt - hoặc kết hợp cả hai) phần lớn là trực giao với OOP. Kế thừa và các lớp hoàn toàn trực giao với OOP. Nếu bạn dành chút thời gian để chơi với io, bạn sẽ thấy điều đó.

Bây giờ bạn có thể hỏi loại hệ thống nào là "tốt hơn", và phương tiện tái sử dụng và kết hợp mã nào. Và cố gắng xác định các ưu điểm và nhược điểm giữa các lựa chọn được thực hiện trong Simula (và sau này được thực hiện trong C ++, Java và C #) và các lựa chọn được thực hiện trong Go. Nhưng đây là tất cả các câu hỏi khác nhau và khác biệt.

Cuối cùng, OOP là một khái niệm rất mơ hồ và tất cả các nỗ lực để thực hiện nó đều có rất nhiều hương vị. Nhưng để thực sự đơn giản hóa mọi thứ, tôi muốn nói rằng ý tưởng cốt lõi của OOP là soạn thảo các hệ thống của các hệ thống con RẮN . Bây giờ điều này hoàn toàn làm mờ đi các mô hình khác, nhưng tôi đoán rằng đó là lý do tại sao các ngôn ngữ đa mô hình đã trở nên phổ biến gần đây và tại sao Google lại tự mình sử dụng nó.

OOP không lỗi thời.

Như Andrea đã nói, đã có nhiều khái niệm được đề xuất thay thế cho các lớp (ví dụ: typklass). OOP có một lợi ích lớn: nó được dạy ở nhiều nơi và văn hóa của OOP chủ yếu được chia sẻ giữa các nhà phát triển.

Điều này cho phép giao tiếp phong phú hơn trong một nhóm. Người ta có thể nói về các nhà máy dễ dàng hơn về các prepromorphic Zygohistomorphic . OOP cấu trúc theo cách bạn sẽ tổ chức và giao tiếp về chương trình của mình với các sơ đồ thường được sử dụng. Đây là một tài sản mạnh mẽ.

Không, không có gì mới ở đây, cũng không phải là lỗi thời. C ++ cũng có các giao diện ngầm ở dạng mẫu, nhưng mọi người vẫn sử dụng các hàm ảo. Bạn cần các giao diện rõ ràng để đối phó với, ví dụ: giao diện nhị phân hoặc giao diện nơi mã khác đơn giản là không được biết đến vào thời gian biên dịch.

Bạn có thể lập luận rằng đây chỉ đơn giản là một trường hợp suy luận và nói rõ ràng, nó không giống như một "mô hình mới" và thực sự chỉ là thuận tiện hơn.