Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

Обсуждение АОП

245
13 июля 2011 года
~ArchimeD~
1.4K / / 24.07.2006
На днях заинтересовался темой - Аспектно-ориентированным программированием.

Пока единственный плюс, который я узрел в статьях:
Цитата:

АОП предлагает средства выделения сквозной функциональности в отдельные программные модули — аспекты.


Мне кажется, что либо я не вполне понимаю ценность этой фичи, либо не вкурил в наличие других вкусностей, но неужели это стоит целой парадигмы?

Не смотря на ряд диферамб про то, как все это круто, конкретных примеров и мануалов - раз-два, и обчелся. Поэтому если кто вникал или использовал, может поделится примерами, или подскажет толковые материалы? Или объяснит, почему это действительно круто. Или, что не круто :)

Большинство примеров - AspectJ (джавовая реализация), меня же особенно интересует, а есть ли подобные фичи у С++? Судя по интернетам, AspectC++ - довольно кастрированная реализация.

З.Ы. в общем, тема-вброс, призванная спровоцировать мозговой штурм :)
З.З.Ы. что-то мне подсказывает, что камрад hardcase в теме, по крайней мере в соответствующем топике на rsdn кто-то из nemerle-девелоперов засветился.

416
14 июля 2011 года
MaitreDesir
380 / / 02.01.2008
Я конечно в таких вопросах далеко не специалист ("дырка от носика чайника" скорей), но судя по статье - это не парадигма, а примочка к ООП, которая позволяет "ленивым" программистам грамотно использовать парадигму ООП. Вот из вики:
Цитата:
но некоторую функциональность с помощью предложенных методов невозможно выделить в отдельные сущности


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

245
14 июля 2011 года
~ArchimeD~
1.4K / / 24.07.2006
Мне на самом деле тоже кажется, что это дополненеи ООП.
Вот что мне знакомый гейм девелопер писал про применение сабжа в разработке игр:

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



Говорит, что написание на с++ в стиле АОП эту проблему если не полностью решает, то значительно упрощает

11
14 июля 2011 года
oxotnik333
2.9K / / 03.08.2007
ИМХО, если перевести на рабоче-пролетарский язык, то при ООП сабж превращается в дополнительный объект, куда скидывается всяческий "мусор" не подходящий под какую либо классификацию объектов, т.е. по большому счету что то из этой оперы: http://forum.codenet.ru/threads/67786-GUI-%D0%B2-%D0%BA%D0%B0%D1%87%D0%B5%D1%81%D1%82%D0%B2%D0%B5-%D0%BC%D0%B5%D0%BD%D0%B5%D0%B4%D0%B6%D0%B5%D1%80%D0%B0-%D0%BE%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
416
14 июля 2011 года
MaitreDesir
380 / / 02.01.2008
Кстати, если затронуть вопрос логгирования (ведения лога). В статье указано, что
Цитата:
Ведение лога и обработка ошибок — типичные примеры сквозной функциональности

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

341
14 июля 2011 года
Der Meister
874 / / 21.12.2007
Цитата: MaitreDesir
Ни разу не сталкивался с функциональностью в объектно-ориентированном коде, которую нельзя было бы отдать отдельной сущности, применяя для этого декомпозицию и играя с областями видимости. А значит - не хотелось заморачиваться, либо (что вероятнее, почему слово "ленивым" и в кавычках) дальнейшая декомпозиция вызывала определенные трудности в аспектах времени и сложности.

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

245
15 июля 2011 года
~ArchimeD~
1.4K / / 24.07.2006
Цитата: oxotnik333
ИМХО, если перевести на рабоче-пролетарский язык, то при ООП сабж превращается в дополнительный объект, куда скидывается всяческий "мусор" не подходящий под какую либо классификацию объектов


Ну грубо говоря, так и есть, только это называется не мусор, а сквозная функциональность :)

Цитата: MaitreDesir

Приведу пример. Писал в свое время физическую модель сложного процесса (раскрой металлической ленты со всеми процессами подготовки и обработки - отжиг, прокатка, травление, дрессировка, резы). Была конечно куча объектов, классы наследовали друг друга и так далее. Но все классы были наследованы от класса, реализующего (кроме прочих) интерфейс ILogSubsystem с единственным методом Log, который все что и умел - в главном классе-"сцене" коммандовал экземпляру класса LogFile вывод переданного сообщения, а в наследниках - вызывал Log у родителя, причем совершенно не интересовало, кто родитель, поскольку все реализовывали ILogSubsystem. Таким образом, для ведения лога был сделан один класс, для работы с логом (LogFile), и реализован один метод у двух классов - у сцены, и у объекта сцены. Все потомки автоматом умели вести лог, причем логика лога была строго обособлена в одной сущности.



Может лог и не самый удачный пример. Но, насколько я понимаю, одной из фич АОП является возможность как раз таки отойти от такой модели, и иметь динамическое связывание.

2Der Meister мсье, я так понимю, в теме?

11
15 июля 2011 года
oxotnik333
2.9K / / 03.08.2007
Цитата: ~ArchimeD~
Ну грубо говоря, так и есть, только это называется не мусор, а сквозная функциональность :)

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

6
15 июля 2011 года
George
4.1K / / 05.01.2007
Потихоньку начал ковырять Питон. Есть там такая штука - декораторы. Как я понял (из мануалов и объяснений Ромика) декоратор - это функция, получающая на входе другую функцию и некоторым образом модифицирующая ее. К примеру валидацию входящих данный можно вынести в такой декоратор, а затем уже проверенные данные передавать функции, которая отправит их на сервер. Вся соль в том, что декоратор можно применять не к какой-то одной конкретной функции, а к любой вообще.
Вроде так, хотя могу врать, сам еще "плаваю" пока в этом.
11
15 июля 2011 года
oxotnik333
2.9K / / 03.08.2007
Цитата: George
Потихоньку начал ковырять Питон. Есть там такая штука - декораторы. Как я понял (из мануалов и объяснений Ромика) декоратор - это функция, получающая на входе другую функцию и некоторым образом модифицирующая ее. К примеру валидацию входящих данный можно вынести в такой декоратор, а затем уже проверенные данные передавать функции, которая отправит их на сервер. Вся соль в том, что декоратор можно применять не к какой-то одной конкретной функции, а к любой вообще.
Вроде так, хотя могу врать, сам еще "плаваю" пока в этом.


Жорж, как это относится к сабжу? Или ты освоил новую фишку, и теперь хвастаешься? :trollface

6
15 июля 2011 года
George
4.1K / / 05.01.2007
Цитата: oxotnik333
Жорж, как это относится к сабжу? Или ты освоил новую фишку, и теперь хвастаешься? :trollface


Это вообще-то пример АОП. Сквозную функциональность в питоне можно выделять в декораторы.
З.Ы. Еще раз прошу, если называет кто меня Жоржем, не мешало бы своё имя сообщить. А иначе - у меня есть ник.

11
15 июля 2011 года
oxotnik333
2.9K / / 03.08.2007
Цитата: George
З.Ы. Еще раз прошу, если называет кто меня Жоржем, не мешало бы своё имя сообщить. А иначе - у меня есть ник.


Ну дык ник и читаем в русской транскрипции.

14
15 июля 2011 года
Phodopus
3.3K / / 19.06.2008
Как член группы "простившие Оксотника" требую немедленно исполнить девиз группы! :mad:
245
19 июля 2011 года
~ArchimeD~
1.4K / / 24.07.2006
Имхо, хороший пример, но к сожалению. специфичный для Java. Трассировка приложения ведется автоматически.

В контексте С++, пояснение плюсов программирования в стиле АОП. Правда, однозначно убедительно, на мой взгляд, автор не сумел рассказать, почему нельзя обойтись без АОП :) Но стоит еще почитать комментрии.
Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог