Đến muộn trong trò chơi, nhưng tôi cung cấp điều này cho các nhà phát triển sau này có thể vấp phải câu hỏi này.
Tôi thực sự khuyên bạn nên chống lại AOP nếu ứng dụng của bạn phụ thuộc vào nó để hoạt động chính xác. Các khía cạnh hoạt động như thế này:
- Lời khuyên (hành vi bổ sung) được áp dụng cho
- Tham gia các điểm (những nơi có thể gắn mã bổ sung, như một phương thức bắt đầu hoặc kết thúc hoặc khi một sự kiện đã kích hoạt)
- ... trong đó điểm cắt (một mẫu phát hiện xem các điểm nối đã cho có khớp hay không)
Đối với bất cứ ai đã làm máy tính trong một thời gian dài, thực tế là các mẫu được sử dụng có thể là một cái gì đó để xem xét kỹ. Vì vậy, đây là một ví dụ về một điểm cắt phù hợp với bất kỳ phương thức nào được đặt tên setbất kể đối số:
call(* set(..))
Vì vậy, đó là một điểm khá sâu rộng và rõ ràng là nên xử lý việc này một cách cẩn thận (không có ý định chơi chữ) vì bạn đang áp dụng lời khuyên cho nhiều việc.
Hoặc chết tiệt, hãy áp dụng lời khuyên cho tất cả mọi thứ , bất kể tên hoặc chữ ký!
execution(* *(..))
Vì vậy, rõ ràng chúng ta nên cẩn thận vì có rất nhiều sức mạnh ở đây, nhưng đây không phải là một cuộc tranh cãi với các khía cạnh - đó là một lập luận cần thận trọng bởi vì có rất nhiều sức mạnh ở đây và việc khớp mẫu có thể dễ dàng bị phá vỡ (chỉ cần nhấn vào công cụ tìm kiếm yêu thích của bạn aop lỗi và vui chơi).
Vì vậy, đây là những gì trông giống như một điểm cắt tương đối an toàn:
pointcut setter(): target(Point) &&
( call(void setX(int)) ||
call(void setY(int)) );
Điều đó cung cấp lời khuyên rõ ràng nếu các phương thức được đặt tên setXhoặc setYtrên một Pointđối tượng được tìm thấy. Các phương thức chỉ có thể nhận ints và chúng phải được void. Trông khá an toàn, phải không? Chà, điều đó an toàn nếu những phương pháp đó tồn tại và bạn đã áp dụng lời khuyên chính xác. Nếu không, quá tệ; Nó âm thầm thất bại.
Để đưa ra một ví dụ, một người bạn đã cố gắng gỡ lỗi một ứng dụng Java trong đó mọi người một lần trong một thời gian tuyệt vời, nó sẽ trả về dữ liệu không chính xác. Đó là một thất bại không thường xuyên và dường như không tương quan với bất kỳ sự kiện hoặc dữ liệu cụ thể nào. Đó là một lỗi luồng, một cái gì đó rất khó kiểm tra hoặc phát hiện. Hóa ra, họ đã sử dụng các khía cạnh để khóa các phương thức và làm cho chúng trở thành "luồng an toàn", nhưng một lập trình viên đã đổi tên một phương thức và một điểm cắt không khớp với nó, do đó gây ra sự phá vỡ im lặng của ứng dụng.
Vì vậy, tôi nói với mọi người rằng nếu họ phải sử dụng AOP, để xử lý các khía cạnh như ngoại lệ: trong một hệ thống được thiết kế tốt và nếu không có gì sai, họ có thể gỡ bỏ và phần mềm vẫn hoạt động chính xác. Tuy nhiên, nếu chức năng của chương trình phụ thuộc vào AOP, bạn giới thiệu một sự mong manh cho chương trình của bạn là không chính đáng.
Vì vậy, ghi nhật ký, gỡ lỗi và truy tìm là những ví dụ tuyệt vời về hành vi hoàn hảo cho các khía cạnh, nhưng bảo mật? Không. Chủ đề an toàn? Không.
Để thay thế mạnh mẽ cho AOP, xem các đặc điểm . Thay vì được gắn vào ngôn ngữ, chúng được tích hợp trực tiếp vào ngôn ngữ, không cần IDE "nhận biết đặc điểm" (mặc dù nó có thể giúp đỡ) và có lỗi thời gian biên dịch nếu không có phương pháp bạn yêu cầu. Các đặc điểm thực hiện công việc sạch sẽ hơn nhiều trong việc xử lý tách các mối quan tâm vì vấn đề được xác định rõ hơn ngay từ đầu. Tôi sử dụng chúng rộng rãi và chúng thật tuyệt vời.