Пізно в грі, але я надаю це для пізніших розробників, які можуть натрапити на це питання.
Я б настійно радив проти AOP, якщо ваша програма залежить від її роботи. Аспекти працюють так:
- Поради (додаткова поведінка) застосовуються до
- Точки приєднання (місця, де може бути доданий додатковий код, такий спосіб починається чи закінчується, або коли спрацьовує певна подія)
- ... де точка (шаблон, який визначає, чи відповідає збіг заданої точки з'єднання)
Для кожного, хто довгий час займався комп’ютером, факт, що використовуються візерунки, може стати уважним уважною увагою. Отож ось приклад точки, яка відповідає будь-якому методу, названому setнезалежно від аргументів:
call(* set(..))
Отож, це досить глибока точкова точка, і повинно бути зрозуміло, що рекомендується обережно поводитися з цим (не каламбур), оскільки ви застосовуєте поради щодо багатьох речей.
Або чортів, давайте застосовувати поради до всього , незалежно від імені чи підпису!
execution(* *(..))
Отже, очевидно, що ми повинні бути обережними, оскільки тут багато сил, але це не аргумент проти аспектів - це аргумент для обережності, оскільки тут багато потужності, а відповідність шаблонів може легко зійти з ладу (просто натисніть на вашу улюблену пошукову систему для aop клопи і веселитися).
Ось ось, що виглядає як відносно безпечний пункт:
pointcut setter(): target(Point) &&
( call(void setX(int)) ||
call(void setY(int)) );
Це прямо дає поради, якщо знайдені методи, названі setXабо setYна Pointоб’єкті. Методи можуть отримувати лише ints, і вони повинні бути void. Виглядає досить безпечно, правда? Ну, це безпечно, якщо ці методи існують, і ви застосували правильну пораду. Якщо ні, то занадто погано; це мовчки не вдається.
Для прикладу, друг намагався налагодити додаток Java, де кожен раз у чудовий час він повертав би невірні дані. Це було нечастою невдачею і, схоже, не було пов'язане з якоюсь конкретною подією чи даними зокрема. Це була помилка з різьбленням, те, що загалом важко перевірити або виявити. Як виявляється, вони використовували аспекти, щоб заблокувати методи та зробити їх "безпечними для потоків", але програміст перейменував метод, і точкова точка не змогла відповідати йому, тим самим спричинивши мовчазну поломку програми.
Таким чином, я кажу людям, що якщо вони повинні використовувати AOP, вони розглядають такі аспекти, як винятки: у добре розробленій системі, і якщо нічого не піде не так, їх можна буде видалити, а програмне забезпечення все ще працює належним чином. Однак якщо функціональність програми залежить від AOP, ви вводите в свою програму неміцність, що не є обґрунтованою.
Таким чином, ведення журналів, налагодження та відстеження - це чудові приклади поведінки, ідеальної для аспектів, але безпеки? Ні. Безпека нитки? Ні.
Щоб отримати надійну альтернативу AOP, ознайомтеся з ознаками . Замість того, щоб бути прив'язаними до мови, вони інтегруються в неї безпосередньо, не потребують IDE, що «знає ознаки» (хоча це може допомогти) і мають збої в процесі компіляції, якщо необхідних методів немає. Риси виконують набагато чіткішу роботу з вирішення проблем, оскільки проблема була краще визначена з самого початку. Я їх широко використовую, і вони фантастичні.