Аспектно-ориентированное программирование (АОП) представляет собой одну из концепций программирования, которая является дальнейшим развитием процедурного и объектно-ориентированного программирования (ООП). Данная методология призвана снизить время, стоимость и сложность разработки современного ПО, в котором, как привило, можно выделить определенные части, или аспекты, отвечающие за ту или иную функциональность, реализация которой рассредоточена по коду программы, но состоит из схожих кусков кода. У кого-нибудь уже есть опыт использования АОП. Делитесь.
Отождествите аспект с вариантом использования. А средства реализации имеют принципиальное значения? AspectJ
"Отождествите аспект с вариантом использования." это один множества вариантов перекладывания аспектов на диаграммы UML. однако к согласию относительно UML так и не пришли, а другого средства визуализации пока не придумали. "А средства реализации имеют принципиальное значения?" мне кажется, если мы говорим о структурном и процедурном программировании, то должны быть средства реализации этого, например процедурные языки программирвоания. если говорим про объекты, то тоже самое. ну и АОП в том же духе. ПС. я думаю, что предметный разговор не получится, так ни у кого нет ни мало-мальски какого-либо опыта в использовании АОП, отсутсвует язык моделирования, да и средство реализации всего одно.
Это я назвал одну из реализаций. У микрософта, на сколько знаю, то же есть что-то похожее поверх dcom (хотя не буду на этом настаивать). Не понял, если А Вы у Винера поищите
HorstWessel, "похожее поверх dcom" вот это мне кажется несколько мимо кассы. "Не понял, если" а что тут непонятного. на вопрос что мне можно использовать для моделирования схемы БД я могу ответить IDEF1X, IE, и т.д; для функционального моделирования систем - IDEF0; для объектного моделирования - UML, Шлеер-Меллора и т.д. то на вопрос, что мне использовать для аспектного моделирования до сих пор нет ответа, ну, если хотите, стандарта. "А Вы у Винера поищите" это Ваше высказывание непонятно.
Да нет. В процессе разработки сложных систем на DCOM программисты решают две задачи: создают компоненты сущности и компоненты-сервисы, в которые вовлечены компоненты сущности. И если код компонентов сущности хорошо "локализован", отлично просматривается и готов для повторного использования, то фрагменты кода компонентов-сервисов оказывается распределеными по всей системе дублируя друг-друга. Это приводит к проблеме запутанности кода (code tangling). В рамках АОП утверждается, что никакая технология проектирования не поможет решить данную проблему, если только мы будем оставаться в рамках языка, ориентированного только на разработку компонентов. Для программирования сервисов, обеспечивающих взаимодействие объектов, нужны специальные средства, возможно специальные языки. Согласно парадигме АОП после этапа кодирования компонентов и аспектов на соответствующих языках выполняется автоматическое построение оптимизированного для выполнения (но не для просмотра и модификации) кода. Этот финальный процесс называется слиянием ( weaving ). И я не пойму что тут непонятного. Используйте UML, а стандарты подтянутся.
я еще раз повторю. мимо кассы. не путайте понятия! DCOM - это распределенная модель объектов, реализовать DCOM можно на ассемблере, си, паскале, си++, объектном паскале и т.д. DCOM - это не язык и не средство реализации. а то, что Вы слышали это рекламный слоган, о том, что объекты СОМ+ имеют теперь декларативные атрибуты, куда перемещены независимые от логики приложения аспекты. "И я не пойму что тут непонятного. Используйте UML, а стандарты подтянутся." с таким подходом схему БД можно в Word рисовать, причем каждый по-своему. еще раз повторю, UML - для объектов, АОП - почти ортогонально ООП, что тогда значат Ваши слова использовать UML? ПС . а реализаций, кстати, поболе наберется - пару десятков точно будет.
Я Вам еще раз повторю. Не путайте понятия: Что касается Ваших тезисов относительно DCOM, я с вами согласен и поэтому написал: "...после этапа кодирования компонентов и аспектов на соответствующих языках выполняется...". И не о декларативных атрибутах я вел речь. А в отношении моделирования баз данных в Word, я бы так и сделал. И всем без исключения было бы понятно что это. А знаете почему? Потому что у меня в базе данных никогда нет ничего кроме таблиц и внешних ключей. Более того я вообще никогда не создаю их сам. За меня это делает сервер приложений. Я создаю компоненты-сущности (для моделирования иногда использую UML) и декларирую их отношения - один ко многим и др. У сервера приложений есть все необходимые службы для управления этими компонентами и мне нет дела как они храняться в базе данных и что это вообще такое. Проблемы возникают на следующем шаге - программировании компонентов сервисов. Вот тут-то аспекты и появляются. Для DCOM будет то же самое.
Ну что ж, читаем сначала и вместе: "ПО, в котором, как привило, можно выделить определенные части, или аспекты, отвечающие за ту или иную функциональность, реализация которой рассредоточена по коду программы, но состоит из схожих кусков кода" У Вас: "атрибуты, куда перемещены независимые от логики приложения аспекты". Я выделил слово "атрибуты" потому что, как я уже писал, реализация объектов-сущностей не вызывает никаких трудностей. У сущности есть атрибуты, они могут изменяться и для их реализации достаточно парадигмы ООП. Код объектов-сущностей идеален с точки зрения ООП. Но проблема в том, что хотя компоненты сущности и могут изменять свои атрибуты, они (сущности) ничего не знают о контексте, в котором эти изменения происходят. Это уже зависит от логики приложения. То есть, помимо сущностей, необходима реализация еще и действий, или сервисов. На практике же получается, что логически разные действия очень часто используют одни и те же фрагменты кода. Это не редко приводит к запутанности. Теперь главное, аспекты в принципе не применимы к атрибутам, но применимы к действиям над атрибутами.
в терминах СОМ+ атрибуты - это именно то, о чем вы говорите - "функциональность, рассредоточенная по коду программы, но состоящая из схожих кусков кода". однако связь атрибутов в СОМ+ и АОП - это не более чем рекламный слоган. так что ДСОМ здесь ни причем. так что я ничего не попутал.
могу, вот например: для COM+ для каждого его метода в его атрибутах можно задать набор ролей, кторые имеют право его вызывать. т.е., так как COM+ объект работает в контексте объекта ObjectContext, то проверка происходит не в пользовательском объекте, а, грубо говоря в другом объекте. т.е. в коде программы отсутствует код, который выполняют проверку на возможность вызова метода пользователем.
ну и теперь посмотрите на свой пример: вы демонстируете не атрибуты как функциональность..., а службу безопасности, которая управляется атрибутами. Служба безопасности это сервис. Атрибут, сам по себе, не имеет никакого отношения к аспектам в контексте АОП. А вот реализация сервиса безопасности COM+, вполне возможно, использует АОП. HorstWessel добавил [date]1116569354[/date]: Если, действительно, в реализации COM+, использовались аспекты, то это уже не рекламный слоган. И если Вам известны детали реализации служб COM+, в части где использовались аспекты и что полезного они привнесли, тогда говорте. Или если Вы сами использовади аспекты тогда это интересно. Иначе бестолковая беседа.