Tôi đã nghe nhiều lần về lập trình hướng theo khía cạnh, chủ yếu là công nghệ "thế hệ tiếp theo" trong lập trình và sẽ 'giết' OOP.
Đúng không? Là OOP sẽ chết hoặc những gì có thể là lý do cho điều đó?
Cái chết của công nghệ OOP [đóng cửa]
Câu trả lời:
Bất cứ khi nào ai đó nói với bạn rằng một công nghệ phần mềm sẽ giết chết một người khác hoặc thống trị toàn bộ thị trường / sử dụng / đối tượng, hãy nhớ điều này:
Một hệ sinh thái lành mạnh (năng động nhưng ổn định) được tạo thành từ nhiều loại khác nhau.
Điều đó có nghĩa là bất kỳ công nghệ thổi phồng mới nào cũng sẽ đi qua đường cong cường điệu và cuối cùng sẽ tìm thấy mục đích cụ thể của nó thông qua thời gian và trải nghiệm với nó.
Điều đó cũng có nghĩa là một khái niệm cực đoan như lập trình hướng theo khía cạnh là hữu ích nếu nó cần thiết, có nghĩa là, không phải luôn luôn và không thường xuyên, vì chi phí ngụ ý.
Nhưng nó đã có sẵn, như OOProgramming, như lập trình chung, như lập trình chức năng, như lập trình thủ tục, v.v.
Bạn có để ý rằng các ngôn ngữ được sử dụng nhiều hơn (và phổ biến gây tranh cãi) và phổ biến rộng rãi trong cuộc sống thực là "không thuần túy" không? Đó là bởi vì cho phép một số mô hình làm cho chúng linh hoạt hơn để thay đổi bối cảnh theo thời gian và chúng lấp đầy nhiều ngóc ngách sử dụng hơn.
1
+1 cho 'không thuần túy'. Các ngôn ngữ OOP thuần túy đáng chú ý đã chết, ngoại trừ việc sử dụng / học thuật rất thích hợp.
—
jv42
Điều gì chúng ta sẽ xem xét một ngôn ngữ OO thuần túy? Smalltalk?
—
Zhehao Mao
OOP sẽ không chết vì AOP. AOP thêm một số giá trị, nhưng nó sống cùng tồn tại hoàn hảo với OOP. Tôi không nghĩ rằng lập trình chức năng cũng sẽ giết chết OOP. OOP quá phù hợp với nhiều loại vấn đề, sẽ không có ý nghĩa gì khi thay thế nó bằng mô hình chức năng.
Điều đó rất chủ quan. Tôi không nghĩ OOP phù hợp với một miền có vấn đề cụ thể, nó phù hợp với cách nhà phát triển cụ thể đưa ra giải pháp. OOP sẽ không chết vì các nhà phát triển không thể thực hiện chuyển đổi mô hình.
—
Raynos
Ví dụ kinh điển trong đó OOP phù hợp là GUI. Thật khó để tưởng tượng một API cho bộ công cụ GUI không phải là OO, ngay cả khi ngôn ngữ không. (Được cấp, đó không phải là cách thuật ngữ miền vấn đề thường được sử dụng) Để đưa ra ví dụ về miền có vấn đề thực sự trong đó OOP phù hợp tốt: Tự động hóa kho. Mô hình hóa các phương tiện lưu trữ và truy xuất và các hoạt động của chúng là nơi OOP cảm thấy như một sự phù hợp tự nhiên.
—
user281377
@ammoQ, GUI thật kinh khủng khi được thể hiện trong OO. Đó là lý do tại sao tất cả các API đang trôi dạt về phía DSL (WPF và tương tự). Không khó để tưởng tượng, nói, Tk - không có dấu vết nào của OOP ở đó, nhưng nó vẫn rất tuyệt (đối với lập trình, không phải vì giao diện & cảm giác của nó), tốt hơn nhiều so với bất kỳ bộ công cụ OO Java nào. OOP thực sự phù hợp với bất kỳ mô phỏng dựa trên đại lý nào (như những gì bạn đã liệt kê), nhưng đó là một tỷ lệ nhỏ trong các vấn đề hiện có.
—
SK-logic
Nhìn vào các ví dụ đầu tiên của tk tôi có thể tìm thấy, làm thế nào mà không phải là OO? Từ hướng dẫn: "Widget là các đối tượng, thể hiện của các lớp đại diện cho các nút, khung, v.v." tkdocs.com/tutorial/con accept.html Thậm chí, nhiều hơn nữa, bản thân DSL rất phụ thuộc vào lập trình OO. Vì vậy, tôi không thực sự hiểu những gì bạn đang cố gắng nói?
—
Inca
Câu trả lời ngắn gọn: Không, tôi không nghĩ vậy.
Câu trả lời dài hơn: Theo những gì tôi hiểu về AOP, bản thân nó không phải là một mô hình lập trình (như trong, nó không thay thế OOP), mà là một bổ sung, một bộ công cụ giúp bạn viết các phương thức ngắn hơn, các lớp đơn giản hơn, đơn trách nhiệm , vân vân. Nhưng nó không thay thế OOP.
Điều mà (ít nhất là một phần) thay thế hoặc thêm vào OOP là lập trình chức năng, thực sự là một mô hình lập trình khác (mặc dù nó có thể được trộn lẫn với OOP, ví dụ như trong ngôn ngữ lập trình Scala ). Nó thích các cơ sở dữ liệu bất biến và tất cả các loại tính năng ưa thích có xu hướng làm nản lòng các nhà phát triển OOP, đặc biệt là khi nói đến sự tương tranh.
Chức năng <-> Bắt buộc là dòng. OOP song song với nó. Tôi nghĩ rằng thủ tục là ở đầu kia của OOP nhưng tôi không chắc chắn. Tất nhiên, thật thú vị khi mô hình chức năng cũ hơn mô hình OOP :)
—
Raynos
@Raynos, không có đường thẳng. OOP chỉ là một sự trừu tượng hóa ngôn ngữ kim loại nhỏ bên trong một tập hợp lớn (vô hạn) các ngôn ngữ trừu tượng có thể. Và tất nhiên là vô cùng ngu ngốc khi giới hạn bản thân với bất kỳ ai trong số họ.
—
SK-logic
OOP được nói đến ít hơn những ngày này vì nó được coi là cách tiếp cận thực tế trong nhiều tình huống. AOP không bao giờ lên khỏi mặt đất như bất kỳ loại phong trào quần chúng.
Tôi nhớ đã nghe về Lập trình hướng theo khía cạnh lần đầu tiên ngồi trong Hướng dẫn OOPSLA '97. Họ nói rằng nó sẽ giết OO trước đó. Kể từ đó, OO chỉ phát triển ngoài mong đợi hoang dã nhất. AOP, vẫn hầu như không được biết đến với cơ bản không có tác động đến ngành công nghiệp điện toán. Tôi nghĩ rằng câu trả lời là rõ ràng rằng AOP không phải là kẻ giết người OO.
Nhìn vào một số hệ thống AOP hiện có. Chúng phụ thuộc vào việc bạn có một số mã được viết dưới dạng nào đó - ví dụ, Spring AOP phụ thuộc vào việc bạn có các phương thức được định nghĩa trên một lớp. Castle Windsor hỗ trợ nó trong C #, một ngôn ngữ hướng đối tượng.
Về mặt lý thuyết bạn có thể chuyển từ OOP sang lập trình có cấu trúc và vẫn giữ AOP, nhưng trong thực tế, điều đó sẽ khó khăn. Thật dễ dàng để phân lớp một cái gì đó, ghi đè phương thức có liên quan để gọi bộ lọc trước / sau thích hợp và vượt qua nó trong quá trình tiêm phụ thuộc.
Thật khó so với việc viết lại các cuộc gọi phương thức tĩnh để định tuyến đến một phương thức trampoline được thiết kế để gọi các bộ lọc do người dùng xác định.
Vì vậy, từ quan điểm thực hiện chung, AOP yêu cầu OOP.
Trong khi OOP chắc chắn không phải là viên đạn bạc, điều tương tự cũng có thể nói với AOP. Nó hỗ trợ thiết kế dựa trên thành phần, tuy nhiên trong sơ đồ lớn hơn, các thành phần của bạn là các đối tượng mới và các giao diện thành phần về cơ bản là một danh sách các phương thức giao dịch, không phải là OOP đúng.
Hơn nữa AOP và thiết kế dựa trên thành phần hỗ trợ Mô hình dữ liệu thiếu máu, những người thông minh hơn tôi tự mình chỉ trích.
http://martinfowler.com/bliki/AnemiaDomainModel.html
(Tôi biết bài viết trên là cũ, nhưng có liên quan đáng ngạc nhiên)
Điểm mấu chốt là các hệ thống AOP vẫn ở đây nhưng chúng cũng không hoàn hảo. Không có hệ thống nào là hoàn hảo.