Обсуждение АОП
Пока единственный плюс, который я узрел в статьях:
АОП предлагает средства выделения сквозной функциональности в отдельные программные модули — аспекты.
Мне кажется, что либо я не вполне понимаю ценность этой фичи, либо не вкурил в наличие других вкусностей, но неужели это стоит целой парадигмы?
Не смотря на ряд диферамб про то, как все это круто, конкретных примеров и мануалов - раз-два, и обчелся. Поэтому если кто вникал или использовал, может поделится примерами, или подскажет толковые материалы? Или объяснит, почему это действительно круто. Или, что не круто :)
Большинство примеров - AspectJ (джавовая реализация), меня же особенно интересует, а есть ли подобные фичи у С++? Судя по интернетам, AspectC++ - довольно кастрированная реализация.
З.Ы. в общем, тема-вброс, призванная спровоцировать мозговой штурм :)
З.З.Ы. что-то мне подсказывает, что камрад hardcase в теме, по крайней мере в соответствующем топике на rsdn кто-то из nemerle-девелоперов засветился.
Ну как это так? Ни разу не сталкивался с функциональностью в объектно-ориентированном коде, которую нельзя было бы отдать отдельной сущности, применяя для этого декомпозицию и играя с областями видимости. А значит - не хотелось заморачиваться, либо (что вероятнее, почему слово "ленивым" и в кавычках) дальнейшая декомпозиция вызывала определенные трудности в аспектах времени и сложности.
Да, в такой ситуации удобно воспользоваться аспектно-ориентированной моделью, но реализовывать всю программу именно так - глупо имхо. Поэтому нисколько не умаляя значение и полезность идеи, не согласен считать её полноценной парадигмой.
Вот что мне знакомый гейм девелопер писал про применение сабжа в разработке игр:
Вторая задача: чтобы это поведение гибко "подключалось" к любому объекту сцены. Без переписывания кода, есс-нно.
Говорит, что написание на с++ в стиле АОП эту проблему если не полностью решает, то значительно упрощает
. С одной стороны это конечно так, но с другой стороны - почему??
Приведу пример. Писал в свое время физическую модель сложного процесса (раскрой металлической ленты со всеми процессами подготовки и обработки - отжиг, прокатка, травление, дрессировка, резы). Была конечно куча объектов, классы наследовали друг друга и так далее. Но все классы были наследованы от класса, реализующего (кроме прочих) интерфейс ILogSubsystem с единственным методом Log, который все что и умел - в главном классе-"сцене" коммандовал экземпляру класса LogFile вывод переданного сообщения, а в наследниках - вызывал Log у родителя, причем совершенно не интересовало, кто родитель, поскольку все реализовывали ILogSubsystem. Таким образом, для ведения лога был сделан один класс, для работы с логом (LogFile), и реализован один метод у двух классов - у сцены, и у объекта сцены. Все потомки автоматом умели вести лог, причем логика лога была строго обособлена в одной сущности.
Понятно, что при большой вложенности объектов это вызовет тормоза (куча методов вызывается у родителей), но во-первых, производительность особо не волновала, а во-вторых, когда решили лог перенести в БД потребовалось чуть поменять один класс.
Зачем мне в такой ситуации АОП?
Тем не менее, такие задачи есть. В OO-программе сквозной является любая функциональность, по которой не проведена декомпозиция. Есть модели, принципиально не поддающиеся объектной декомпозиции, либо их объектно-ориентированная реализация вводит утилитарных, не имеющих аналогов и смысла в концептуальной модели, сущностей на порядок больше, чем предметных (т. е. для впихивания бизнес-логики в рамки ООП иногда приходится писать целую среду исполнения). Зачастую приходится объединять несовместимые модели, даже если они хорошо поддаются объектой декомпозиции по отдельности (например, сериализация объектов домена).
Ну грубо говоря, так и есть, только это называется не мусор, а сквозная функциональность :)
Приведу пример. Писал в свое время физическую модель сложного процесса (раскрой металлической ленты со всеми процессами подготовки и обработки - отжиг, прокатка, травление, дрессировка, резы). Была конечно куча объектов, классы наследовали друг друга и так далее. Но все классы были наследованы от класса, реализующего (кроме прочих) интерфейс ILogSubsystem с единственным методом Log, который все что и умел - в главном классе-"сцене" коммандовал экземпляру класса LogFile вывод переданного сообщения, а в наследниках - вызывал Log у родителя, причем совершенно не интересовало, кто родитель, поскольку все реализовывали ILogSubsystem. Таким образом, для ведения лога был сделан один класс, для работы с логом (LogFile), и реализован один метод у двух классов - у сцены, и у объекта сцены. Все потомки автоматом умели вести лог, причем логика лога была строго обособлена в одной сущности.
Может лог и не самый удачный пример. Но, насколько я понимаю, одной из фич АОП является возможность как раз таки отойти от такой модели, и иметь динамическое связывание.
2Der Meister мсье, я так понимю, в теме?
Тогда я не совсем понимаю, к чему все эти напряги с выводом отдельной концепции. И так в концепции ООП один объект определяет один тип поведения. Для связи разных объектов используется еще один объект (иногда его называют бизнес-логикой). Какой практический смысл в АОП? Только больше запутать? Или на собеедовании козырнуть умным словом?
Вроде так, хотя могу врать, сам еще "плаваю" пока в этом.
Вроде так, хотя могу врать, сам еще "плаваю" пока в этом.
Жорж, как это относится к сабжу? Или ты освоил новую фишку, и теперь хвастаешься? :trollface
Это вообще-то пример АОП. Сквозную функциональность в питоне можно выделять в декораторы.
З.Ы. Еще раз прошу, если называет кто меня Жоржем, не мешало бы своё имя сообщить. А иначе - у меня есть ник.
Ну дык ник и читаем в русской транскрипции.
В контексте С++, пояснение плюсов программирования в стиле АОП. Правда, однозначно убедительно, на мой взгляд, автор не сумел рассказать, почему нельзя обойтись без АОП :) Но стоит еще почитать комментрии.