Прочитал пару статей про аспектно-ориентированное программирование - красивые слова, обещания разных прелестей и т.д. У меня вопрос. Кто-нибудь реально использовал такой подход? Для каких задач? Какие впечатления? Лично у меня сложилось мнение, что ОАП-код поддерживать куда сложнее, чем ООП-код. Прав ли я?

Блин, тему неправильно назвал...
Модераторы, исправьте, пожалуйста, "ОАП" на "АОП".
Не... Лучше на "Аспектно-ориентированное программирование"

Аспектно Ориентированное Программирование зародилось в 97-ом году и до сих пор не нашло применения. Так что не переживай, рано об нём ещё говорить  

У нас в институте системного программирования семинары сейчас по этому делу проходят, никто толком ещё даже представить не может, как это можно использовать.

Вообще да, ООП тоже долго не могло завоевать популярность, подобную нынешней.


Значит слова, слова, слова? Вот я и озадачился, всё так прелестно, красиво, удобно, но эффективного применения этому так найти не смог.

Целые НИИ пытаются найти это применение  У нас, например, руководитель горит этой идеей просто  

После опубликования в 1997 г. про АОП все забыли. И только где-то через лет этак 5 кто-то раскопал и раскрутил это дело. Так что для 1997 г. это было действительно сильно. А сейчас в это направление ринулась толпа жаждающих острых ощущений и в результате получилось "как всегда". А подсаживаться сейчас на АОР я бы сказал уже поздно. Это уже в основном пройденный этап. Хотя конечно еще дают под это слово деньги, но в целом "всеобщего счастья" достигнуто не было, и интерес спадает. 


Это общий подход, поэтому какого-то конкретного применения у него нет. Это то же самое, что спросить, где можно применить ООП. Ответ: везде. Это означает, что надо просто по-другому взглянуть на устройство программы и представить ее в виде аспектов. 

Но на самом деле я считаю, что ценность АОП вовсе не в применении. Этот подход открыл новый взгляд на программу. Он показал, что есть вещи, которые нельзя реализовать в ООП. Это проблема повторяющегося кода, который невозможно поместить в один модуль с помощью ООП. В результате вся программа состоит из одних и тех же фрагментов. В АОП это хорошо очень иллюстрируется, а предлагаемое решение, откровенно говоря, негодное. 

--
http://conceptoriented.com

Юзается и ещё как. Я не знаю про другие платформы, но в Java точно. Аннотации довольно довно вошли в состав расширений от BEA и IBM, а начиная с 5-й версии уже в стандарте языка Java.

Кроме того, очень раскрученный и модный framework "Spring" основан как раз на АОП. Используется, используется - не переживайте. 

По-моему, в .NET тоже юзают.

Аннотации не связаны с АОП -- это отдельный подход. Хотя аннотации могут использоваться в т.ч. и для АОП.


Да, АОП используется в JBoss, Spring и др. системах. Там провда это не программирование, а на уровне конфигурации (пишешь XML-файлы). Программирование в основном на AspectJ.


Юзают много, а вот пользы от этого мало. Дело в том, что АОП содержит ряд глубоких логических дефектов. Поэтому это в целом тупиковая ветвь развития. Но до сих пор модная, а потому, если есть интерес или кто-то платит деньги, то можно поковыряться. 

Подробней? Можно ссылками 

Ссылок у меня нет, да и в таких вопросах обычно их довольно мало (слишком тонкая материя). 

Вот нескольк направлений:

•  Идея использовать регулярные выражения это средство вводить ошибки в программу. Например, если написать "set*" (все методы, начинающиеся на set), то в будущем кто-то может определить метод, не подозревая, что он находится "под воздействием" аспекта. С другой стороны, убрать регулярные выражения нельзя, поскольку это одна из основ АОП.
•  Представим, что есть модуль А (аспект), откуда осуществляется модификация кода в модулях Б, В и т.д. (классы). В АОП модуль А объявляет точки в программе, где надо изменить поведение (модули Б, А,...), которые сами ничего не знают об этом. Это очень плохо. Надо с точностью наоборот. т.е. модули, которые хотят поддержки, должны об этом объявить, тогда как модуль А не должен знать, что он используется в Б, В и др.
•  Аспект задумывался как аналог класса, т.е. была надежда, что эти две конструкции будут объединяться. К сожалению надеждам не суждено было сбыться. Это по-прежнему две разные конструкции, а значит возникает путаница и проблемы с их использованием. Вместо упрощения программирования получаем усложение. 
•  Когда много аспектов очень трудно проследить за их взаимодействием. В частности, есть проблема циклов. Представим, что есть 100 аспектов и 100 класов, которые друг друга начинают изменять.
•  АОП все-таки осталось средством программирования типа макросов, которое может помочь что-то автоматизировать, но само устройство систем осталось объектно-ориектированным.

Но я хотел бы еще раз повторить, что АОП открыло целый пласт проблем, которые существуют и которые надо решать, и в этом его главная и очень важная роль.

--
http://conceptoriented.com

По моему всяидея была реализовать в одуле А точки расширения, так что другие модули смогут изменять его поведение. ИМХО это не минус.

С остальным согласен, хотя сам по теме не очень ещё... 

Это, фактически, event'ы. В питоне, если не ошибаюсь, что-то подобное реализовано. Идея АОП же как раз противоположная: целевой модуль не должен ничего знать о том, как им управляют. Это даёт важное преимущество: мы можем, например, написать отдельно функции почтовой программы (в "чистом виде"), не определяя как обрабатываемая информация будет взаимодействовать с пользователем, а модуль UI реализовать в виде аспекта.

Также очень удобными были бы аспекты при отладке: можно было бы писать аспект-логгеры.


У нас в институте был хороший семинар по АОП, но про то, что аспект задумывался как аналог класса я не услышал ни разу. Да и это бредово: класс - это средство удобного объединения данных и функций для работы с ними по сути. Аспекты же ближе к простым функциям - они лишь выполняют некоторые действия, но запускаются автоматически при определённых условиях (которые, кстати говоря, определяются на этапе компиляции).

Т.е. возможно одновременно сочетать два подхода ООП и АОП? Использовать аспекты для "модификации поведения" методов класса?

Слово "задумывался" действительно здесь не подходит, поскольку аспекты это как раз попытка зделать то, чего нельзя реализовать классами в ООП (например, повторяющийся код). Дело в том, что понятие аспекта хотели как можно ближе свести к классам и в конечном итоге построить новую объединенную конструкцию. Зачем? Да просто потому, что программировать с двумя конструкциями сложно и неудобно. Любое неоправданное усложнение убивает подход (если конечно он претендует на что-то серьезное). Именно поэтому внешне аспекты оформили как классы, ввели поля, методы и пр. ОО-ерунду. Но в конце концов классы остались классами (и не впитали в себя АО-элементы), а аспекты остались аспектами (и не впитали полностью ОО черты). А раз так, то нового подхода не получилось. По определенным причинам и не могло получиться (к сожалению). 

Кстати, определение условий срабатывания функций аспекта на этапе компиляции это плохо (вернее очень ограниченно, я бы даже сказал примитивно). Эта одна из причин, почему АОП можно рассматриваь как навороченный препроцессор, т.е. это механизм, привинченный сбоку к ООП. АОП можно охарактеризовать как метод подстановки кода. Т.е. программист указывает на определенном языке куда и как надо вставить код.

--
http://conceptoriented.com

Я с аспектами особо дела не имел, только читал о них. Но насколько известно мне, аспекты архитектурно как раз дополняют классы. Т.е. классы используются для тех сущностей предметной области, которые по смыслу отделимы, замкнуты и целостны. Но иногда такой подход становится слишком жёстким и неудобным. Аспекты же применяются для внесения кроссклассовой функциональности, т.е. для описания однородного поведения сразу нескольких классов, которое не связано с их спецификой, а представляет из себя какую-то общесистемную логику.

Иерархия классов в языках с невозможностью множественного наследования имеет вид пирамиды. Аспекты же можно представить, как горизонтальные сетевые связки классов, объединения, не носящие иерархического характера, но описывающие некоторые сходные аспекты специфичного для каждого класса поведения.

Подробнее можно почитать здесь.