Ну вроде удобно и правильно, но я может из-за отсутствия опыта и понимания не стал бы АОП выделять настолько отдельно, т.е. ООП после процедурного программирования намного революционнее имхо.
Мы использовали АОП в своем Java проекте когда нужно было расширить уже готовую функциональность какого-то модуля так, чтобы его поведение не изменилось для других старых компонент которые его используют. Использование кучи if-проверок не подходит.
Мы реализовали это так:
Есть класс для подписчиков на события. События – это любой вызов "до" или "после" метода какого-либо класса, а также внутренние "точки" с идентификаторами. Перед инстанциированием этого класса, мы настраиваем АОП движок и добавляем в него подписщики на различные события.
спасибо.
прочитаю.
грубо говоря это создание класов отвечающее за определенные действия…
а другой их все связывает…
и можно всегда свободно дописать ещё какой то модуль ?
или бред говорю?
парадигма программирования, основанная на идее разделения функциональности, особенно сквозной функциональности, для улучшения разбиения программы на модули.
21 марта 2009 в 19:04
Ну вроде удобно и правильно, но я может из-за отсутствия опыта и понимания не стал бы АОП выделять настолько отдельно, т.е. ООП после процедурного программирования намного революционнее имхо.
21 марта 2009 в 13:01
Очень хорошо идея АОП описывается в языке AspectJ – надстройка над Java
//www.eclipse.org/aspectj/
Также есть варианты использования АОП на php
//wiki.agiledev.ru/doku.php?id=aop:aop_php
Мы использовали АОП в своем Java проекте когда нужно было расширить уже готовую функциональность какого-то модуля так, чтобы его поведение не изменилось для других старых компонент которые его используют. Использование кучи if-проверок не подходит.
Мы реализовали это так:
Есть класс для подписчиков на события. События – это любой вызов "до" или "после" метода какого-либо класса, а также внутренние "точки" с идентификаторами. Перед инстанциированием этого класса, мы настраиваем АОП движок и добавляем в него подписщики на различные события.
20 марта 2009 в 22:01
Да, всегда можно добавить еще аспектов.
20 марта 2009 в 21:02
спасибо.
прочитаю.
грубо говоря это создание класов отвечающее за определенные действия…
а другой их все связывает…
и можно всегда свободно дописать ещё какой то модуль ?
или бред говорю?
20 марта 2009 в 21:01
парадигма программирования, основанная на идее разделения функциональности, особенно сквозной функциональности, для улучшения разбиения программы на модули.
20 марта 2009 в 21:01
javable. com/columns/aop/workshop/01/
вот на затравку…