Là lập trình hướng theo khía cạnh là một cách hiểu sai?

Từ tất cả mọi thứ tôi đã học về "Lập trình hướng theo khía cạnh" hoặc "Phát triển phần mềm định hướng theo khía cạnh", gắn nhãn đó là mô hình lập trình hoặc phương pháp luận dường như không chính xác. Từ những gì tôi có thể nói nó không phải là một kỹ thuật cơ bản để lập trình.

Để hiểu rõ ý nghĩa của "mô hình" và "phương pháp luận", vui lòng tham khảo các định nghĩa sau đây từ Từ điển Di sản Hoa Kỳ. So sánh mức độ "lập trình hướng đối tượng" tốt hay kém đối với từng ứng dụng so với mức độ phù hợp của AOP.

Mô hình: Một tập hợp các giả định, khái niệm, giá trị và thực tiễn cấu thành cách nhìn nhận thực tế cho cộng đồng chia sẻ chúng, đặc biệt là trong một ngành học trí tuệ.

Phương pháp: Một cơ thể thực hành, thủ tục và quy tắc được sử dụng bởi những người làm việc trong một ngành học hoặc tham gia vào một cuộc điều tra; một tập hợp các phương pháp làm việc.

"Thuốc dựa trên bằng chứng" thỏa mãn định nghĩa về mô hình, nhưng "thuốc dựa trên cắt tử cung" sẽ là một cách hiểu sai vì không gian vấn đề quá hẹp.

Tôi nhận được ấn tượng rằng AOP có thể bị đặt tên sai bởi vì dựa trên hậu tố "lập trình định hướng", AOP bị cáo buộc là cả một mô hình và một phương pháp theo cùng một cách "Lập trình hướng đối tượng".

Cả hai thuật ngữ này (mô hình và phương pháp luận) chỉ ra một kỹ thuật cơ bản, trong đó những gì tôi hiểu về các khía cạnh là một công nghệ để giải quyết phạm vi vấn đề hẹp, có thể so sánh về độ lớn với tính năng biến tĩnh của Java.

Nếu đúng là các khía cạnh giải quyết được một loạt các vấn đề hẹp và AOP không phải là một cách hiểu sai, thì tại sao tất cả các kỹ thuật lập trình không được đưa ra hậu tố "lập trình định hướng", chẳng hạn như "lập trình hướng kế thừa", "phụ thuộc" lập trình định hướng, "hay" lập trình hướng phạm vi? "

Tôi nghĩ rằng đây thực sự là một vấn đề iffy vì định nghĩa về "phương pháp luận" và "mô hình" và "lập trình định hướng" có khả năng hơi lỏng lẻo trong bối cảnh này, nhưng tôi sẽ chơi trò bênh vực của quỷ và đi với " có, đó là một cách gọi sai ".

Ngay cả khi bạn không sử dụng các tính năng AOP hoặc AOP để giải quyết vấn đề, bạn vẫn sẽ suy nghĩ về các khía cạnh đó - bạn có thể viết chúng dưới dạng tài liệu ở đâu đó hoặc bạn có thể sử dụng trình tạo mã - theo cách này, khái niệm các khía cạnh vẫn còn đó. Điều đó cũng có thể đi với bất kỳ mô hình nào; mặc dù nó sẽ khá xấu xí, bạn vẫn có thể làm OOP trong C.

Vậy điều đó có nghĩa là AOP cũng giống như phương pháp của OOP phải không? Tôi nghĩ có nhiều hơn thế.

Lý do là một phương pháp đưa ra giải pháp cho một loại vấn đề cụ thể . Bạn không sử dụng nhiều hơn một phương pháp để giải quyết vấn đề khái niệm, mặc dù bạn có thể sử dụng hai hoặc nhiều hơn trong sơ đồ lớn hơn. Bạn có thể sử dụng OOP và thủ tục để viết UI nhập dữ liệu, nhưng bạn chỉ sử dụng OOP để mô tả cấu trúc trừu tượng của UI và bạn chỉ sử dụng các thủ tục (chính xác hơn là các phương thức) để mô tả hành vi của nó. Tại các thành phần cốt lõi của một vấn đề, các phương pháp là loại trừ lẫn nhau - và AOP vẫn có thể tham gia giải quyết vấn đề với chức năng, OOP hoặc mã thủ tục.

AOP giải quyết các vấn đề theo nghĩa là nó làm giảm số lượng mã lặp lại, nhưng đó cũng nằm trong mô tả công việc của một tính năng ngôn ngữ. Bạn chưa thực sự giải quyết bất kỳ vấn đề thực tế nào bằng cách nói rằng bạn sẽ có được trình biên dịch hoặc thời gian chạy để tiêm một số mã mà bạn không phải viết rõ ràng; bạn vừa làm cho mã của mình có tổ chức hơn một chút. Tuyên bố rằng "tất cả các chức năng của tôi sẽ ghi lại thời gian bắt đầu và kết thúc của chúng" không phải là giải pháp cho một vấn đề; nó chỉ là một tuyên bố vấn đề.

Tôi nghĩ rằng nó sẽ phù hợp hơn với họ khi chỉ đơn giản được gọi là "Các khía cạnh", như là một tính năng ngôn ngữ.

Tất cả các phương pháp phát triển chỉ đơn thuần là cách nghĩ về tổ chức mã. Mỗi phương pháp phát triển có thể tạo ra mã tìm kiếm rất khác nhau hoặc chúng có thể tạo ra mã tương tự. Họ cũng có thể yêu cầu thư viện hoặc các tính năng ngôn ngữ để được hỗ trợ.

Ví dụ, trong C ++, AOP thường được triển khai bằng cách sử dụng các lớp tính trạng và đa hình thời gian biên dịch. Đây hoàn toàn không phải là một "tính năng" ngôn ngữ - bạn xây dựng các khía cạnh khác nhau của loại hình của mình và kết hợp chúng theo cách bạn muốn với các mẫu.

Trong các ngôn ngữ như Java không có thứ gì đó giống như các mẫu, cuối cùng bạn cần sử dụng các tính năng ngôn ngữ chuyên dụng được cung cấp bởi các bộ tiền xử lý (ví dụ AspectJ) để lập trình theo hướng theo khía cạnh, đơn giản vì ngôn ngữ gốc không có khả năng thực hiện AOP chính nó.

Kết quả là, các chương trình AOP sẽ trông rất khác so với C ++ so với Java - nhưng điều quan trọng nhất là cách lập trình viên nghĩ về thiết kế của anh ấy hoặc cô ấy, chứ không phải về cách mã.

Do đó, AOP chắc chắn là một phương pháp phát triển.

Có hai điều đang chơi ở đây - mô hình lập trình so với phương pháp phát triển phần mềm .

Đúng, Lập trình hướng theo khía cạnh là một mô hình lập trình. Nó tận dụng các tính năng ngôn ngữ nhất định để thể hiện các cấu trúc cần thiết để thực hiện một tác vụ hoặc để làm cho mã dễ đọc hơn. Đó là một kỹ thuật có thể được sử dụng bởi một lập trình viên. Rất nhiều lần, bạn thấy AOP được sử dụng cùng với Lập trình hướng đối tượng để loại bỏ các mối quan tâm xuyên suốt. Tuy nhiên, bạn cũng có thể triển khai lập trình hướng theo khía cạnh trên cùng một ngôn ngữ chức năng. Đây không nhất thiết là một mô hình hoàn toàn mới, mà là một phần mở rộng cho OOP và lập trình chức năng để giảm bớt các vấn đề đã biết. Lý do cốt lõi tại sao tôi tin rằng nó nên được coi là một mô hình là nó thay đổi cách bạn nghĩ về việc đạt được một giải pháp cho vấn đề. Cũng giống như lập trình chức năng, lập trình thủ tục, lập trình logic và lập trình hướng đối tượng, tất cả đều có các giải pháp khác nhau cho cùng một vấn đề, lập trình hướng theo khía cạnh thêm một giải pháp khác cho tập hợp vấn đề.

Không, Lập trình hướng theo khía cạnh không phải là một phương pháp phát triển. Phương pháp phát triển là một khung mà bạn có thể sử dụng để tạo ra một hệ thống phần mềm. Nó chỉ định những nhiệm vụ bạn thực hiện và cách bạn thực hiện chúng, từ các yêu cầu cho đến cuối đời. AOP không nói gì về điều này. Tuy nhiên, một số mô hình lập trình đã dẫn đến các phương pháp tiếp cận phương pháp phát triển cho vòng đời phần mềm. Có một cách tiếp cận được gọi là Kỹ thuật phần mềm hướng đối tượng, được phát triển bởi Ivar Jacobsonđã chỉ định một vòng đời hoàn chỉnh để thiết kế và phát triển các hệ thống hướng đối tượng, nhưng không được ưa chuộng và đã được thay thế bởi UML và Quy trình hợp nhất Rational. Tôi thực sự không thấy AOP ảnh hưởng đến các phương pháp giống như cách mà OOP đã làm. Trong thực tế, chỉ nhìn vào các xu hướng dường như chỉ ra rằng các phương pháp nên vượt qua ngôn ngữ và mô hình được sử dụng để xây dựng phần mềm. Có thể có các kỹ thuật mô hình và từ vựng tập trung vào AOP được sử dụng trong quá trình thiết kế và phát triển, nhưng tôi không thấy một phương pháp toàn diện tập trung vào AOP.