Bài thuyết trình của Casey Muratori có tựa đề The Big OOPs: Anatomy of a Thirty-Five Year Mistake đã khơi dậy cuộc tranh luận sôi nổi trong cộng đồng lập trình về những giả định cơ bản làm nền tảng cho lập trình hướng đối tượng (OOP). Bài nói chuyện kéo dài gần hai giờ đồng hồ này truy tìm quá trình phát triển lịch sử của OOP từ năm 1963 đến 1998, lập luận rằng một cách tiếp cận cụ thể để tổ chức mã nguồn đã tạo ra hàng thập kỷ phức tạp không cần thiết trong phát triển phần mềm.
Lập luận cốt lõi: Phân cấp mô hình miền là một sai lầm
Luận điểm trung tâm của Muratori tập trung vào cái mà ông gọi là phân cấp đóng gói tại thời điểm biên dịch phù hợp với mô hình miền. Điều này đề cập đến thực hành phổ biến của việc tổ chức các lớp mã nguồn để phản ánh các mối quan hệ thế giới thực - như có lớp Car kế thừa từ lớp Vehicle, lớp này kế thừa từ lớp Transportation. Cuộc thảo luận cộng đồng tiết lộ rằng nhiều nhà phát triển được dạy cách tiếp cận này như là cách đúng đắn để thực hiện OOP, với việc kế thừa đại diện cho các mối quan hệ ngữ nghĩa is-a từ miền vấn đề.
Bài nói chuyện truy tìm cách tiếp cận này trở lại với Simula , nơi nó có ý nghĩa vì ngôn ngữ được thiết kế cho mô phỏng. Tuy nhiên, khi những khái niệm này chuyển sang C++ và sau đó là Java , chúng trở thành thực hành phổ quát được áp dụng cho tất cả các vấn đề phần mềm, bất kể việc mô hình hóa miền có phù hợp hay không.
Dòng thời gian lịch sử phát triển OOP:
- 1963: Các khái niệm ECS sơ khai xuất hiện trong Sketchpad
- 1967: Simula 67 giới thiệu các lớp và hàm ảo
- 1980s-1990s: C++ phổ biến các hệ thống phân cấp mô hình miền
- 1998: Thief: The Dark Project trình diễn kiến trúc ECS hiện đại
- Hiện tại: Các game engine như Unity và Unreal áp dụng các mẫu ECS
Entity Component Systems: Giải pháp thay thế đã bị lãng quên
Một phần đáng kể của cuộc thảo luận cộng đồng tập trung vào Entity Component Systems (ECS), mà Muratori trình bày như một giải pháp thay thế đã tồn tại từ sớm như năm 1963 nhưng phần lớn bị lãng quên. ECS tổ chức mã nguồn xung quanh các khả năng tính toán thay vì phân cấp miền. Thay vì có kế thừa lớp cứng nhắc, các thực thể được cấu thành từ các thành phần có thể được thêm hoặc loại bỏ một cách động, với các hệ thống hoạt động trên các thực thể có kết hợp thành phần cụ thể.
Các nhà phát triển game trong cuộc thảo luận lưu ý rằng ECS đã trở nên ngày càng phổ biến trong lĩnh vực của họ, với các engine lớn như Unity và Unreal Engine áp dụng những mẫu này. Cách tiếp cận này cho phép mã nguồn linh hoạt và dễ bảo trì hơn, đặc biệt trong các hệ thống phức tạp nơi các đối tượng cần thể hiện nhiều hành vi không phù hợp gọn gàng vào các danh mục phân cấp.
So sánh các Mô hình Lập trình Chính:
| Phương pháp | Tổ chức | Tính linh hoạt | Trường hợp sử dụng |
|---|---|---|---|
| OOP Truyền thống | Phân cấp miền ( Car → Vehicle ) | Thấp - kế thừa cứng nhắc | Ứng dụng doanh nghiệp, phần mềm thời kỳ đầu |
| Entity Component Systems | Khả năng tính toán | Cao - kết hợp động | Game, mô phỏng, hệ thống phức tạp |
| Lập trình Hàm | Hàm toán học | Cao - hàm có thể kết hợp | Xử lý dữ liệu, hệ thống đồng thời |
| Lập trình Thủ tục | Các thao tác tuần tự | Trung bình - hàm mô-đun | Lập trình hệ thống, tiện ích |
Cộng đồng chia rẽ về giá trị của OOP
Cộng đồng lập trình dường như chia rẽ về việc liệu bản thân OOP có vấn đề hay chỉ là những triển khai cụ thể của nó. Một số nhà phát triển chia sẻ kinh nghiệm bị chỉ trích vì đặt câu hỏi về tính chính thống của OOP trong suốt sự nghiệp của họ, mô tả những tình huống mà họ bị coi là kém kỹ năng hơn vì thích các cách tiếp cận hàm số hoặc thủ tục.
Tôi đã phàn nàn rất nhiều về OOP trong suốt 25 năm làm nhà phát triển... khi tôi bắt đầu phàn nàn với các đồng nghiệp về cảm xúc của mình, tôi bị tẩy chay và bị cáo buộc là 'không có bộ kỹ năng đủ mạnh.'
Tuy nhiên, những người khác lập luận rằng vấn đề không phải là OOP như một mô hình mà là cách nó được dạy và áp dụng. Họ chỉ ra rằng các ngôn ngữ như Python và thậm chí C++ cho phép nhiều phong cách lập trình, và rằng tính đa hình và đóng gói vẫn là những công cụ có giá trị khi được sử dụng một cách thích hợp.
Tranh luận kỹ thuật về triển khai ngôn ngữ
Một tuyến phụ thú vị trong cuộc thảo luận cộng đồng liên quan đến các tranh luận về điều gì cấu thành lập trình hướng đối tượng ở cấp độ ngôn ngữ. Một số lập luận rằng các ngôn ngữ như Python về bản chất là hướng đối tượng vì mọi thứ được triển khai như các đối tượng bên trong, trong khi những người khác tranh luận rằng các chi tiết triển khai quan trọng ít hơn so với các mẫu lập trình mà nhà phát triển sử dụng.
Cuộc thảo luận kỹ thuật này làm nổi bật sự nhầm lẫn xung quanh thuật ngữ OOP, với các nhà phát triển khác nhau sử dụng thuật ngữ này để có nghĩa khác nhau - từ các tính năng ngôn ngữ như kế thừa đến các mẫu kiến trúc đến các chi tiết triển khai cơ bản.
Kết luận
Phân tích lịch sử của Muratori rõ ràng đã chạm đến một điểm nhạy cảm trong cộng đồng lập trình, xác nhận những kinh nghiệm mà nhiều nhà phát triển đã có với các phân cấp OOP quá phức tạp trong khi cũng thúc đẩy sự phản ánh về các giải pháp thay thế tốt hơn. Cuộc thảo luận cho thấy rằng trong khi các công cụ OOP như tính đa hình và đóng gói vẫn có giá trị, ngành công nghiệp có thể đang chuyển khỏi các cách tiếp cận mô hình hóa miền cứng nhắc hướng tới các mẫu kiến trúc linh hoạt hơn như ECS và các kỹ thuật lập trình hàm số.
Cuộc tranh luận phản ánh những câu hỏi rộng lớn hơn về cách các mô hình lập trình phát triển và tại sao các cách tiếp cận nhất định trở nên cố hữu bất chấp những hạn chế của chúng. Khi cộng đồng tiếp tục vật lộn với những ý tưởng này, rõ ràng là nghiên cứu của Muratori đã cung cấp bối cảnh lịch sử có giá trị để hiểu cách chúng ta đến được với các thực hành lập trình hiện tại và nơi chúng ta có thể đi tiếp theo.
Tham khảo: The Big OOPs: Anatomy of a Thirty-Five Year Mistake