Là mô hình lập trình hướng đối tượng đã lỗi thời vì nó chống mô-đun và chống song song? [đóng cửa]

Tôi đã đọc bài báo gây tranh cãi Dạy FP cho sinh viên năm nhất được đăng bởi Robert Harper, một giáo sư ở CMU. Ông tuyên bố rằng CMU sẽ không còn dạy lập trình hướng đối tượng trong khóa học giới thiệu vì nó không phù hợp với chương trình giảng dạy CS hiện đại.

Và ông tuyên bố rằng:

Lập trình hướng đối tượng được loại bỏ hoàn toàn khỏi chương trình giới thiệu, bởi vì nó vừa chống mô-đun vừa chống song song bởi chính bản chất của nó.

Tại sao coi OOP là chống mô-đun và chống song song?

Vui lòng xem xét, rằng nhu cầu của Harper trong việc giảng dạy một lớp học chương trình CS giới thiệu rất khác so với nhu cầu của một dự án thực tế . Công việc của anh là dạy các khái niệm cơ bản (ví dụ mô đun, song song, cảm ứng) cho sinh viên năm nhất. Vì vậy, điều rất quan trọng là ngôn ngữ (và mô hình) được chọn có thể diễn đạt các khái niệm này với càng ít lễ (cú pháp và khái niệm) càng tốt. Sự quen thuộc, hỗ trợ công cụ, thư viện có sẵn, hiệu suất thực thi, vv hoàn toàn không liên quan trong bối cảnh này. Vì vậy, hãy ghi nhớ điều này khi xem xét ...

Quan điểm cho rằng OO là kết quả chống mô-đun từ số lượng lớn các phụ thuộc cho các lớp khác, ngay cả các đối tượng của các lớp được thiết kế tốt có xu hướng kết thúc. Rằng đây là một vấn đề - ngay cả trong mắt những người đề xướng OO - trở nên rõ ràng khi bạn nhìn vào sự phổ biến của các khuôn khổ , bài báo, sách và bài đăng trên blog trong những năm qua (cũng là sự nổi lên của giả và cuống là thú vị).

Một gợi ý khác là tầm quan trọng của Mẫu thiết kế và sự phức tạp của việc triển khai chúng - so với một số mô hình lập trình khác - ví dụ: Factories, Builder, Adaptor, Bridge, Decorator, Facade, Command, Iterator, Mediator, Observer, Strateg and Template Method và có thể Tất cả đều theo cách nào đó liên quan đến việc cải thiện tính mô đun của mã OO.

Kế thừa cũng có vấn đề (ví dụ: Bài toán lớp cơ sở mong manh ) và tính đa hình (kiểu phụ) quyến rũ người ta để làm tăng việc thực hiện thuật toán giữa nhiều lớp, trong đó các thay đổi có thể gợn qua toàn bộ chuỗi thừa kế (lên và xuống!).

Trách nhiệm chống song song có liên quan đến sự nhấn mạnh của trạng thái so với tính toán (hay còn gọi là tính đột biến so với tính bất biến). Cái trước làm cho nó liên quan nhiều hơn đến việc thể hiện sự phụ thuộc của các tính toán con (mà Harper đang thực hiện song song!) Vì bạn thường không thể suy ra vị trí mà trạng thái được quản lý (còn gọi là tệp, trong đó biến thể hiện được khai báo) bên ngoài các tác nhân sẽ thay đổi nó vào thời điểm nào.

Việc nhấn mạnh vào tính bất biến và tính toán làm cho việc thể hiện sự phụ thuộc của các tính toán con dễ dàng hơn nhiều, vì không có quản lý nhà nước, chỉ có các chức năng / tính toán được kết hợp tại nơi bạn muốn thể hiện sự phụ thuộc của các tính toán con.

Đây có lẽ là một tuyên bố táo bạo để thực hiện, nhưng tôi bằng cách nào đó nghi ngờ, Robert Harper này không bao giờ thực sự viết phần mềm thực tế trong cuộc sống của mình. Tất cả những gì anh ta có vẻ quan tâm đến mình là ML và hệ thống loại thống kê. Đóng góp lớn như có thể có thể có, tôi không thấy những tuyên bố của anh ấy về OOP có liên quan như thế nào.

Bài viết này không gây tranh cãi. Tranh cãi liên quan đến kiểm tra, tranh luận và thảo luận. Những gì bạn có ở đây là một số học giả không biết gì, người đưa ra hai lời buộc tội khá cơ bản chỉ trong một tuyên bố duy nhất, mà không bận tâm để cung cấp bất kỳ lý lẽ.

1. Yêu cầu về OOP là chống mô-đun chỉ là vô nghĩa. Tôi thậm chí không biết làm thế nào để đáp ứng với nó, không chỉ không có đối số nào được cung cấp mà cả OOP theo thiết kế là một cách tiếp cận để thiết lập mô đun với sự ghép rất thấp giữa các mô-đun riêng lẻ thông qua phương thức đóng gói và trừu tượng hóa.

2. Yêu cầu OOP là chống song song chỉ thể hiện sự thiếu hiểu biết. OOP không khóa trong mọi quyết định về đồng thời. OOP chỉ ra lệnh ẩn chúng: Nếu được xây dựng chính xác, bạn không thể nói, liệu việc triển khai của một đối tượng có song song hay không.
   Do đó, cuối cùng OOP và lập trình song song là trực giao. Mô hình diễn viên là một mô hình thanh lịch cho sự tương tranh có thể được phản ánh trực tiếp trong một hệ thống đối tượng (nhưng không cần thiết), mang lại sự kết hợp ghê gớm của cả hai.

Vấn đề với OOP là, rất ít người thực sự hiểu nó theo nghĩa Alan Kay định nghĩa nó.

1. OOP là một cách tiếp cận. Trong một số ngôn ngữ, nó được triển khai bằng các mẫu, trong các ngôn ngữ khác, bạn có thể trực tiếp sử dụng các thành ngữ ngôn ngữ tích hợp (ví dụ: Ruby, Objective-C, Smalltalk, Io ).
2. Trái với niềm tin chung, OOP không phải là về các lớp học. Đó là về các đối tượng và các đối tượng là về việc truyền thông điệp hoặc một cách đóng gói và trừu tượng không kém phần rò rỉ.

Đây là lý do tại sao Java là để OOP những cây gậy nhọn để chiến đấu với hải quân. Điều này cũng đúng với nhiều thứ gọi là "ngôn ngữ OOP", nhưng điều về Java là, dường như đó là niềm tin phổ biến tại các trường Đại học, rằng Java nên được sử dụng để dạy OOP.

Tôi đồng ý với tất cả những người cho rằng giới thiệu về OOP với Java nên được xóa khỏi chương trình giảng dạy CS. Tôi cũng nghĩ rằng những người rõ ràng thiếu hiểu biết cơ bản về OOP không nên dạy nó. Vì vậy, có lẽ sẽ tốt hơn nếu Bob gắn bó với ML cho các khóa học của mình và chỉ đơn giản là dạy những gì anh ấy có một sự hiểu biết vững chắc.
Ngay bây giờ OOP là một nghi thức thời trang, mà mọi người thích gắn bó với mọi thứ. Điều này gây hại cho OOP và nói mọi người. OOP không lỗi thời. Thời kỳ vàng son của OOP vẫn chưa đến, khi mọi người cuối cùng đã hiểu những gì nó là về những gì nó là không về (ví dụ như giải quyết mọi vấn đề có thể bằng cách sử dụng từ khóa class500 lần).

Bạn có được nhiệt tình của tất cả các sọc.

Lập trình hướng đối tượng không phải là viên đạn bạc. Nó chưa bao giờ. Nó là gì, là một nạn nhân của sự cường điệu. Không thể tránh khỏi, mọi người phát ốm vì sự cường điệu và phản ứng dữ dội bắt đầu phát triển (bất kể tiện ích thực tế của mô hình).

Hai mươi năm nữa, chúng ta sẽ có một số phản ứng dữ dội khác đối với lập trình chức năng.

Tôi không thể trả lời đầy đủ câu hỏi này vì người ta chỉ có thể đoán thứ hai những suy nghĩ mơ hồ của tác giả. Tôi hoàn toàn nghi ngờ rằng bài viết này sắp gây ra một số bối rối cho tác giả của nó. Không có gì về OOP có thể gợi ý rằng nó không phải là mô-đun hay song song:

Tính mô đun : Một khía cạnh chính của OOP là nó thực sự là mô đun (nhưng mô đun có nghĩa là những thứ khác nhau trong các bối cảnh khác nhau). Vì vậy, bất kể tác giả đang nói về khái quát hóa hay lập trình tĩnh, ông đều không chính xác.

Song song hóa : Đối với lập trình song song, hầu hết các khung đã hỗ trợ xen kẽ sau đó xâu chuỗi và bây giờ là song song hóa đúng như những gì chúng ta thấy trong .Net framework 4.0 và các ngôn ngữ OOP bắt vít vào nó.

Tôi nghi ngờ rằng tác giả đã trở thành nạn nhân thời trang ở chỗ có một quan niệm sai lầm rằng lập trình chức năng và OOP là loại trừ lẫn nhau trong việc sử dụng. Có các kiểu chức năng trong các ngôn ngữ OOP được ghi chép tốt, ví dụ, Oliver Sturm đã xuất bản trong lĩnh vực này.

Tác giả khẳng định rằng OOP quá khó để các lập trình viên năm nhất có thể hiểu, điều này có thể đúng - mặc dù tôi nghi ngờ điều đó, đưa ra các yêu cầu đầu vào cho CMU! Các tuyên bố chống mô-đun và chống song song có thể đúng trong một bối cảnh hẹp khi so sánh với các ngôn ngữ chức năng thuần túy, nhưng hầu như không lên án toàn bộ mô hình (dường như chỉ hoạt động tốt đối với những người biết sử dụng nó).

Chương trình giảng dạy được đề xuất sẽ dạy lập trình chức năng trong một lớp, lập trình bắt buộc (thủ tục) trong một lớp khác và cấu trúc dữ liệu trong một lớp khác. Khi một sinh viên năm nhất đã thành thạo 3 điều này, anh ấy / cô ấy nên sẵn sàng học OOP.

Cá nhân tôi nghĩ rằng đó là quá mức cần thiết, nhưng các học giả thích thử những điều mới và cực đoan. Là một đối trọng, MIT đã từng (và có thể vẫn) dạy tất cả các mô hình lập trình chính trong một lớp sinh viên năm nhất.

Thật kỳ lạ, cả hai trường đã sản xuất một số lập trình viên thực sự giỏi. Đi hình.