АОП

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

У кого-нибудь уже есть опыт использования АОП. Делитесь.

 

Отождествите аспект с вариантом использования. А средства реализации имеют принципиальное значения? AspectJ

 

Это я назвал одну из реализаций. У микрософта, на сколько знаю, то же есть что-то похожее поверх dcom (хотя не буду на этом настаивать).

Не понял, если

А Вы у Винера поищите

 

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

И я не пойму что тут непонятного. Используйте UML, а стандарты подтянутся.

 

Я Вам еще раз повторю. Не путайте понятия:

Что касается Ваших тезисов относительно DCOM, я с вами согласен и поэтому написал: "...после этапа кодирования компонентов и аспектов на соответствующих языках выполняется...". И не о декларативных атрибутах я вел речь.

А в отношении моделирования баз данных в Word, я бы так и сделал. И всем без исключения было бы понятно что это. А знаете почему? Потому что у меня в базе данных никогда нет ничего кроме таблиц и внешних ключей. Более того я вообще никогда не создаю их сам. За меня это делает сервер приложений. Я создаю компоненты-сущности (для моделирования иногда использую UML) и декларирую их отношения - один ко многим и др. У сервера приложений есть все необходимые службы для управления этими компонентами и мне нет дела как они храняться в базе данных и что это вообще такое.
Проблемы возникают на следующем шаге - программировании компонентов сервисов. Вот тут-то аспекты и появляются.

Для DCOM будет то же самое.

 

перечитайте мой первый пост.

 

Ну что ж, читаем сначала и вместе: "ПО, в котором, как привило, можно выделить определенные части, или аспекты, отвечающие за ту или иную функциональность, реализация которой рассредоточена по коду программы, но состоит из схожих кусков кода"

У Вас: "атрибуты, куда перемещены независимые от логики приложения аспекты".

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

Теперь главное, аспекты в принципе не применимы к атрибутам, но применимы к действиям над атрибутами.

 

Че? Тут нет ошибки? А пример привести можете?

 

ну и теперь посмотрите на свой пример:
вы демонстируете не атрибуты как функциональность..., а службу безопасности, которая управляется атрибутами. Служба безопасности это сервис. Атрибут, сам по себе, не имеет никакого отношения к аспектам в контексте АОП. А вот реализация сервиса безопасности COM+, вполне возможно, использует АОП.

HorstWessel добавил [date]1116569354[/date]:
Если, действительно, в реализации COM+, использовались аспекты, то это уже не рекламный слоган. И если Вам известны детали реализации служб COM+, в части где использовались аспекты и что полезного они привнесли, тогда говорте. Или если Вы сами использовади аспекты тогда это интересно. Иначе бестолковая беседа.