много... но фундаментально и позновательно ... про сквозную функциональность систем (логирование, аутентификиция и авторизация и т.д.). Описано что такое сквозная функциональность и как ее выделять в отдельные модули используя аспектную декомпозицию и языки, позволяющие это делать. Доказывается, что применение данного подхода имеет смысл (скромно сказано)
Статья произвела на меня хорошее впечатление. Одна из немногих основательных статей по этой теме.
VladD2 -> "Re: Статья про АОП" :
V> Здравствуйте, Miem, Вы писали:
V> Статья нужная, но затянутая и с плохим русским. Ей бы корреторскую V> правку и цены бы ей небыло.
Статья очень-очень нужная. Как говориться — в нужное мество и в нужное
время. Не пришлось изобретать велосипед. Но насчет правки — то же верно.
V> А то автор? Может связаться с ним и предложить опубликовать статью у V> нас (в журнале и на сайте)?
Здравствуйте, VladD2, Вы писали:
VD>Статья нужная, но затянутая и с плохим русским. Ей бы корреторскую правку и цены бы ей небыло. VD>А то автор? Может связаться с ним и предложить опубликовать статью у нас (в журнале и на сайте)?
Вот кто бы занялся списком литературы, который там приведен в конце статьи
А еще было бы замечательно если бы Тимофей, как самый знаток RealProxy ,накатал статью по реализации АОП под .NET на его основе . Я знаю, тут все противники реализаций чего либо на RealProxy, но на нем вполне можно замутить движок-службу, в которой можно регистировать различные расширения нечто вроде контекстный приемников, но гораздо с большими возможностями и тонкостями, например атрибуты к методам, которые будут перехватывать вызовы только к конкретному методу, всякие Nullable, подмена вызовов, задавать условия перехватов и подмены т.д. Регистрация различных типов атрибутов происходит где-нить в инициализации, а далее по коду эти атрибуты начинают активно использоваться приписываясь ко всем мыслимым местам. В общем замутить динамическую реализацию АОП, а не статическую, как в новом языке R# (на основе генерации кода). В прочем, это не одна статья,это целый проект...
Здравствуйте, Miem, Вы писали:
M>много... но фундаментально и позновательно ... про сквозную функциональность систем (логирование, аутентификиция и авторизация и т.д.). Описано что такое сквозная функциональность и как ее выделять в отдельные модули используя аспектную декомпозицию и языки, позволяющие это делать. Доказывается, что применение данного подхода имеет смысл (скромно сказано)
Парадоксально но факт: ничего принципиально нового там нет, всё, что сказано — становилось понятно любому проектировщику ОО-систем ещё эдак лет 10 назад. Правда, справедливости ради, стоит заметить, что всегда было очень трудно доказать очевидные истины окружающим. Зато теперь в спорах появится возможность сослаться на ещё один русскоязычный авторитет и это хорошо. Ситуация — один в один, как и с паттернами.
M>Статья произвела на меня хорошее впечатление. Одна из немногих основательных статей по этой теме.
Она хороша как минимум тем, что в ней сформулированы проблемы и следствия их тривиальных (читай — непродуманных) решений. Эх, вот не появилось в Java шаблонов вовремя — много она всё-таки потеряла. Да и множественного наследования — ой как не хватает.
Павлов указывает недостатки, которые мне кажутся перефразом очень давно сформулированных тезисов:
Плохое прослеживание назначения модуля: Одновременная реализация нескольких требований в одной модульной единице делает неясным соответствие между отдельным требованием и его реализацией, в результате затруднительно понять, что реализует конкретный модуль.
Это можно отнести к любой программе — безотносительно её А- или О- ориентации.
Непригодность кода для повторного использования: В связи с тем, что модуль может использовать в себе некоторую сквозную функциональность с жесткой привязкой к этой функциональности, другие части системы или другие проекты, где может потребоваться уже написанный модуль (но с другими требованиями к сквозной функциональности) не могут использовать уже написанный модуль.
Решалось и решается на уровне проектирования, вернее — декомпозиции. Аспекты, как и объекты — не сами по себе родятся, а только как следствие работы мысли проектировщика.
Большая вероятность ошибок: Запутанность кода влечет за собой код с множеством скрытых проблем.(Вот удивили-то! — ГВ.) Более того, реализация нескольких ортогональных требований в одном модуле может привести к тому что ни одно из них не получит достаточного внимания разработчика.
Проблемы совмещения реализаций аспектов тоже ещё не исследованы и не известны, что отмечает и автор статьи. Кроме того — это же ставилось в вину процедурному подходу.
Трудность в сопровождении: Появление дополнительных требований в будущем потребует переработки текущей реализации, и это может затронуть большинство существующих модулей. (Курсив мой — ГВ.) Модификация каждой отдельной подсистемы в отдельности под новые требования может привести к несовместимости
Именно это ставилось в вину "старому" подходу: структурному проектированию. Не, коллеги, проблема не в ярлыке, который вешается на "методологию", проблема в ДНК проектировщиков.
Проделайте маленький фокус.
Возьмите, например, вот эту цитату:
Аспектно-ориентированная декомпозиция на этапе анализа и проектирования позволяет выделить сквозную функциональность на разных уровнях абстракции и локализовать ее в отдельных модулях-аспектах.
И замените в ней слова "Аспект" на "Объект". Что получили? Гы. Теперь делаем второй трюк: меняем "Аспект" на "Процедура". Ох и любят же апологеты технологий игру словами. Как и я, впрочем. Только я этой игры не скрываю.
Собственно, подобный трюк можно проделать со всей статьёй. А раздел "Варианты применения АОП на разных этапах ЖЦ" напичкан демагогией по самые уши. Например, совершенно непонятно, как именно снимались метрики. Забавно, кстати, уже то, что про метрики неожиданно вспомнили — их довольно долго подвергали жестоким насмешкам. И потом... Halstead Effort 10^4 — это очень простые программы. Сия метрика для реальных модулей представляется 6-9-значным числом и кроме того, зависимость между временем разработки и HEff — нелинейная величина. И потом — она нерепрезантивна, если в реализации системы использовано много идиом на шаблонах (растёт словарь, но сложность восприятия растёт гораздо медленнее). Примерно то же самое можно сказать и об остальных метриках.
Берём пример:
class Main {
//...public void foo(int i) {
Logger.entry("foo(int)");
System.out.println(i++);
Logger.exit("foo(int)");
}
}
И переписываем его в template<> — виде (ага, разумеется — C++ ):
template<typename FrameworkPolicy>
class Main {
//...public void foo(int i) {
FrameworkPolicy::method m(Main::foo); // Явное указание модификации
System.out.println(i++);
}
Отличие принципиально одно — вместо неявной модификации аспектным компилятором имеем явную и контролируемую модификацию кода класса. Бесспорно, АО-компилятор позволяет убрать некоторые помехи в восприятии кода программы, но, блин — это палка о двух концах, один из которых весьма острый и тяжёлый.
Не знаю кому как, а мне лично неявные пертурбации кода ну совсем не нравятся. Кстати, глубокие иерархии (где-то свыше пяти уровней) классов не считаются чем-то хорошим отчасти именно из-за высокой связности и потенциальной опасности модификаций базовых классов.
И опять — "недостатки", на этот раз — подходов к соблюдению контрактов:
Неспособность программных компонентов к повторному использованию. Соблюдение контрактов может быть верно для компонентов только в контексте конкретной системы. В другой системе вполне могут быть другие соглашения, что ведет к модификации кода компонентов
Чушь, извините. Совершенно то же самое можно получить и при бестолковой реализации аспектов. Проблема со свистом обходится глубоой декомпозицией проекта.
Перемешивание кода проверки условий и соблюдения контрактов с основным кодом компонентов. Это снижает способность компонентов быть повторно использованными и снижает "читабельность" их кода.
Опять таки, ровно так же аргументировалась необходимость повсеместного введения ООП. Выносите коды проверок в отдельные модули и наслаждайтесь. В чём проблема-то?
Рассредотачивание кода проверки контрактов по всей системе. Если возникает потребность изменить какое-либо из условий, то необходимо изменить их во всех модулях, на которые оно распространяется.
См. абзацем выше. И не будет никакого рассредоточения.
Громоздкая реализация проверки условий. Изъятие и вставка кода проверки условий в программные компоненты является весьма сложной задачей. Поддерживать проверку условий для всей системы достаточно тяжело.
Или у меня deja vu, или автор просто играет словами, перефразируя один и тот же тезис третий раз. А вы как думаете? Я, например, думаю, что этот и два предыдущих недостатка суть следствия неглубокой декомпозиции и избыточной защищённости, переастающей в дизъюнктивную когерентность реализаций (за объяснением термина интересующихся отсылаю к трудам Barbara Liskov ).
Невозможность соблюдения контрактов во время сборки проекта. В настоящее время реализации компиляторов объектных языков (Java, C++) не позволяют соблюдать проектные соглашения при сборке проекта.
Хоть я и не сидел на полу, но со стула так и не упал. Я конечно, понимаю, что в Java пока нет (вернее — только-только появилась) возможности использовать шаблоны, но зачем же так круто обобщать-то?
Вобщем, хотя я и благодарен автору за статью, но приведённые в ней аргументы вызывают очень неоднозначные впечатления, как и АОП само по себе (притом — давно). АО-компиляторы, конечно, интересная штука, но с их применимостью всё пока выглядит очень... ммм... расплывчато во многом из-за неявности модификаций кода. Собственно АОП, как и ООП сами по себе не позволяют исключить зависимости реализации прикладной функциональности от "сквозной" — это решается на уровне декомпозиции. В смысле — просто декомпозиции по критерию функциональности, без ярлыков типа "аспектная" или "объектная".
А может, лучше уж компиляторы LISP доработать, а то что ни день, то новый этап об-LISP-ливания языков? По крайней мере, LISP честно заявляет о том, что программы и данные — суть одно и то же и играйтесь в методологии сколько влезет. Да, кстати, он тоже работает "несколько" медленнее Java/C++. И будет нам всеобщий ништяк. На некоторое время, разумеется. До следующего поветрия.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Собственно АОП, как и ООП сами по себе не позволяют исключить зависимости реализации прикладной функциональности от "сквозной" — это решается на уровне декомпозиции.
Ну и как ты собираешься подключить хотя бы тот же логгинг к уже почти готовому проекту с помощью декомпозиции?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Собственно АОП, как и ООП сами по себе не позволяют исключить зависимости реализации прикладной функциональности от "сквозной" — это решается на уровне декомпозиции.
IT>Ну и как ты собираешься подключить хотя бы тот же логгинг к уже почти готовому проекту с помощью декомпозиции?
Вопрос не в том, как подключить, а что потом со всем этим делать.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>Собственно АОП, как и ООП сами по себе не позволяют исключить зависимости реализации прикладной функциональности от "сквозной" — это решается на уровне декомпозиции.
IT>>Ну и как ты собираешься подключить хотя бы тот же логгинг к уже почти готовому проекту с помощью декомпозиции?
ГВ>Вопрос не в том, как подключить, а что потом со всем этим делать.
Ну так и как ты собираешься это делать? У тебя есть двести классов бизнес-логики, как ты с помощью декомпозиции добавишь к ним логгинг?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>>Собственно АОП, как и ООП сами по себе не позволяют исключить зависимости реализации прикладной функциональности от "сквозной" — это решается на уровне декомпозиции.
IT>>>Ну и как ты собираешься подключить хотя бы тот же логгинг к уже почти готовому проекту с помощью декомпозиции?
ГВ>>Вопрос не в том, как подключить, а что потом со всем этим делать.
IT>Ну так и как ты собираешься это делать? У тебя есть двести классов бизнес-логики, как ты с помощью декомпозиции добавишь к ним логгинг?
т.б. ты хочешь сказать что АОП это не метод проектирования, а метод добавления?
Здравствуйте, IT, Вы писали:
ГВ>>>>Собственно АОП, как и ООП сами по себе не позволяют исключить зависимости реализации прикладной функциональности от "сквозной" — это решается на уровне декомпозиции.
IT>>>Ну и как ты собираешься подключить хотя бы тот же логгинг к уже почти готовому проекту с помощью декомпозиции?
ГВ>>Вопрос не в том, как подключить, а что потом со всем этим делать.
IT>Ну так и как ты собираешься это делать? У тебя есть двести классов бизнес-логики, как ты с помощью декомпозиции добавишь к ним логгинг?
У меня просто никогда не появлялось двухсот бизнес-классов без фреймворка для них. Да и вообще пример надуманный.
Лог нужен для двух задач: аудита системы пользователем или отладки (трассировка). Трассировочный лог — это одно, и я с трудом представляю ситуацию, когда в конце проекта нужно развешивать лог-вызовы по двумстам классам сразу. (Только не надо песен из репертуара группы "Ты никогда не писал больших программ") Это — ошибка в ДНК проектировщиков, а методологиями она не лечится, а только усугубляется. Если нужен аудит-лог, то опять-таки, решение "вешать лог-вызовы на все бизнес-классы" выглядит решением из серии: "Вы хотели? — Вот вам!", что тоже немного не мой конёк.
Так что, извини, но я не буду решать именно такой задачи: у меня её просто не может быть. И ещё с удовольствием настучу по рукам тому, кто попытается нечто подобное учудить.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Так что, извини, но я не буду решать именно такой задачи: у меня её просто не может быть. И ещё с удовольствием настучу по рукам тому, кто попытается нечто подобное учудить.
Ну вот видишь, сам не любишь группу "Ты никогда не писал больших программ", зато являешься поклонником "Я настучу всем по рукам, кто так будет делать".
Ok, если мы такие нежные и нам нужен жизненный пример на туже тему, то вот тебе пример.
Пусть у нас не 200 классов, а всего лишь 20, в каждом из них в среднем по 10 паблик методов, итого 200 методов. Ну так получилось Теперь нужно добавить ко всем к ним каунтеры нескольких типов, чтобы обеспечить полный мониторинг системы во время эксплуатации.
Теперь влючай свою декомпозицию, выключай демагогию и покажи как это просто делается без AOP.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
ГВ>>Так что, извини, но я не буду решать именно такой задачи: у меня её просто не может быть. И ещё с удовольствием настучу по рукам тому, кто попытается нечто подобное учудить.
IT>Ну вот видишь, сам не любишь группу "Ты никогда не писал больших программ", зато являешься поклонником "Я настучу всем по рукам, кто так будет делать".
Это фигура речи.
IT>Ok, если мы такие нежные и нам нужен жизненный пример на туже тему, то вот тебе пример. IT>Пусть у нас не 200 классов, а всего лишь 20, в каждом из них в среднем по 10 паблик методов, итого 200 методов. Ну так получилось Теперь нужно добавить ко всем к ним каунтеры нескольких типов, чтобы обеспечить полный мониторинг системы во время эксплуатации.
OK, хорошо. Что нужно мониторить? И интересно было бы узнать, откуда взялась такая задача?
IT>Теперь влючай свою декомпозицию, выключай демагогию и покажи как это просто делается без AOP.
Очень забавно — я тебе о том, что прежде чем куда-то ехать, нужно разобраться с картами, а ты предлагаешь лететь по пачке беломора и преодолевать препятствия. Ну что ж, давай поупражняемся.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>OK, хорошо. Что нужно мониторить?
Ну хотя бы длительность и частоту вызовов.
ГВ>И интересно было бы узнать, откуда взялась такая задача?
Требование заказчика. Он обчитался пресрелизов от MS и в конце проекта решил добавить мониторинг сервера приложений.
ГВ>Очень забавно — я тебе о том, что прежде чем куда-то ехать, нужно разобраться с картами, а ты предлагаешь лететь по пачке беломора и преодолевать препятствия. Ну что ж, давай поупражняемся.
Забавно было читать как ты в пух и прах разносил AOP Вот теперь покажи его полную несостоятельность, заменив его своей декомпозицией. Давай, давай.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Очень забавно — я тебе о том, что прежде чем куда-то ехать, нужно разобраться с картами, а ты предлагаешь лететь по пачке беломора и преодолевать препятствия. Ну что ж, давай поупражняемся.
Стоит? Имхо это мат в 2 хода.
У меня несколько иное представление к реализации нежели АОП, но раз разговор о признании самой проблематики. То я бы ответил словами классика о том, что нельзя объять необъятное. Проектирование вещь мощная и полезная, но имеет свой предел, обусловленный знанием (по специальности, предметной области) на текущий момент. И далеко не факт, что предлагаемое решение задачи будет актуальным на момент его применения, не зря говорят "Человек паланирует, бог смеется"
Здравствуйте, IT, Вы писали:
IT>Забавно было читать как ты в пух и прах разносил AOP Вот теперь покажи его полную несостоятельность, заменив его своей декомпозицией. Давай, давай.
в нормальном фреймворке, с хорошо выделенным уровнем бизнес правил, всё это добавляется без труда на любом этапе, причём без препроцессоров типа AspectX'ов, а примеры таких фреймворков никто приводить я думаю не будет.
может тебе стоит почитать ещё что-нибудь кроме пресрелизов от ms?
Здравствуйте, IT, Вы писали:
ГВ>>OK, хорошо. Что нужно мониторить? IT>Ну хотя бы длительность и частоту вызовов.
Для каждого метода БЛ? Или для каждого метода, вызываемого клиентским приложением?
ГВ>>И интересно было бы узнать, откуда взялась такая задача? IT>Требование заказчика. Он обчитался пресрелизов от MS и в конце проекта решил добавить мониторинг сервера приложений.
Так сервера приложений или бизнес-логики, которая на нём крутится?
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Аспектно-ориентированная декомпозиция на этапе анализа и проектирования позволяет выделить сквозную функциональность на разных уровнях абстракции и локализовать ее в отдельных модулях-аспектах.
ГВ>И замените в ней слова "Аспект" на "Объект". :) Что получили? Гы. Теперь делаем второй трюк: меняем "Аспект" на "Процедура". :))) Ох и любят же апологеты технологий игру словами. Как и я, впрочем. :)) Только я этой игры не скрываю. :)))
Суть в том, что с течением времени надо писать системы с все большим функционалом и за все меньшее время. А в последнее время добавилось еще и постоянное изменение требований прямо во время разработки.
Получается что нужно совершенствовать методологию и средства разработки, иначе никогда не удасться выйти из стадии проектирования. А если все-таки долго проектировать, то может и надобность в системе отпасть, потому что нужно будет уже что-то совершенно новое, или вообще клиент уйдет к конкурентам :)
,его мыло указано в начале статьи. Сам наткнулся на сайт случайно. 
Ох и любят же апологеты технологий игру словами. Как и я, впрочем. 
Только я этой игры не скрываю. 
Кстати, глубокие иерархии (где-то свыше пяти уровней) классов не считаются чем-то хорошим отчасти именно из-за высокой связности и потенциальной опасности модификаций базовых классов.
Если нам не помогут, то мы тоже никого не пощадим.
У меня просто никогда не появлялось двухсот бизнес-классов без фреймворка для них. Да и вообще пример надуманный.
