Какие существуют альтернативы сквозным задачам, кроме аспектно-ориентированного программирования? [закрыто]


19

Аспектно-ориентированное программирование обещает решить сквозные проблемы, но я еще не полностью продан. Были ли другие попытки решить эту проблему?


Шаблон посетителя может решить множество ситуаций, которые теперь решаются с помощью АОП.
Стивен Эверс

@SnOrfus: Также смотрите мой ответ ниже, где я говорю о DJ-библиотеке для Java: динамический способ использования шаблона посетителя! Стоит проверить. (Это также общая техника, которую вы можете использовать самостоятельно с Reflection.)
Macneil

Ответы:


7

Когда это возможно, вы можете инкапсулировать сквозные вопросы в отдельные модули, которые затем используются в приложении через внедрение зависимостей. Это позволяет несколько отделить реализацию сквозной задачи от ее использования во всем коде.

Это не всегда работает элегантно, хотя. Вот почему люди пытаются решить проблему с такими вещами, как АОП.


6

Два других варианта, которые я еще не видел, изучены:

Функциональное программирование с помощью монад и стрелок

В FP вы представляете сквозную задачу, как и все остальное: как нечто, переданное при вызове функции. Поскольку делать это явно утомительно, вы можете использовать монады (или, возможно, стрелки), чтобы скрыть дополнительную передаваемую информацию.

Наиболее распространенный пример АОП - ведение журнала. С Monads вы бы создали монаду "Logger", которая хранит список сообщений. Любые функции, которые вы выполняете через LoggerMonad, имеют возможность публиковать сообщения журнала. С помощью стрелок вы смоделируете весь поток данных приложения и в случае необходимости добавите подпрограмму регистрации в модель. Я думаю. Стрелки довольно сложные.

Entity / Компонентное программирование

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

Оба метода позволяют легко легко выполнять сквозные изменения, но оба являются высокоуровневыми архитектурными моделями. Таким образом, вы, вероятно, должны использовать их с самого начала. Модель компонентов теоретически может быть преобразована в существующую систему ООП. Я думаю, монады тоже могут быть, если ваш язык достаточно мощный.


Когда вы говорите о монахах и стрелах, вы должны также упомянуть аппликативные функторы.
Waquo

3

Есть несколько способов решения проблем сквозного характера:

  • Используйте улучшенные шаблоны проектирования, идиомы или механизмы абстракции : код может быть перерезан, даже если он может быть модульным. Чтобы поддерживать код, вам необходимо провести рефакторинг, чтобы использовать технику проектирования, которая может его модульно модифицировать. Такой рефакторинг может привести к перекрестному разрезанию другого вида, но, надеюсь, что перекрестные переходы стабильны и вряд ли изменятся.

  • Разработка более богатых языковых возможностей . Многие проявления перекрестного подхода могут быть решены с помощью более совершенных механизмов абстракции, и иногда необходимы новые языковые возможности. Например, более продвинутые языки, которые включают функциональные и объектно-ориентированные функции, часто не используют столько шаблонов проектирования, потому что они не нужны. Обратите внимание, что сами шаблоны проектирования могут быть перекрестными по своей природе , потому что они описывают роли нескольких различных объектов и классов. В Java отражение часто может использоваться вместо аспекта, хотя и с более высокими затратами времени выполнения. Например, используя отражение, вы можете поддерживать шаблон посетителя для сотен классов с помощью всего лишь нескольких строк кода. DJ-библиотекаиз северо-востока это одно рефлексивное решение, которое делает именно это. Миксины - это мощный метод, доступный в C ++ (но не в Java), и может дать вам некоторые из тех же вариантов использования в качестве аспекта.

  • Обеспечьте лучшую поддержку инструментов : такие методы, как использование grepи выполнение операций рефакторинга, могут иметь дело с проблемами, связанными с пересекающимся кодом. Например, имя метода, объявленного в интерфейсе, может быть использовано во всей программе. (Обратите внимание на техническое различие: это имя метода, а не его реализация, которое пересекает.) Обычно это не проблема в IDE, такой как Eclipse, где вы можете использовать «переименование рефакторинга», чтобы изменить все места в вашем коде, которые используют имя. Таким образом, возможно, вам не понадобятся языковые функции, когда среда программирования достаточно выразительна для вас.

  • Используйте доменные языки : ранние языки аспектов, которые были до AspectJ, были специфичными для домена и применялись только к определенным проблемам, таким как синхронизация потоков или анализ потока данных для эффективного объединения композиций функций. Эти языки были экспериментальными, но казались весьма успешными в модульных задачах, которые в противном случае были сквозными.

  • Используйте методы генеративного программирования . Переход на метауровень можно рассматривать как метод реализации аспектно-ориентированного программирования, но это достаточно большая область, в которой выходят за рамки простых аспектов. Методы генерации (когда программа генерирует исходный код для другой программы) также связаны с предметно-ориентированными языками.

Я считаю, что для всего этого целесообразно изучать АОП. АОП может помочь вам расширить ваши концепции кода, даже если вы не используете язык АОП.


2

В общем, тегирование элементов кода с декларативной функцией, но, в частности, система атрибутов в мире C # /. NET / Mono.


Можете быть более конкретными? То, что вы описываете, это как работают некоторые системы АОП.
Стивен Эверс

2
Это в значительной степени АОП.
Мэтт Х

АОП в его типичном / классическом смысле требует вспомогательного инструмента (аспектного ткачества IDE), чтобы сделать это в большом масштабе. АОП затрудняет рассуждение о коде только из первичного исходного кода. Труднее предсказать поведение ваших компонентов, когда ваша программа заражена аспектными зомби. Атрибуты или теги предоставляют аналогичную функциональность, но с явным представлением в исходном коде.

Обратите внимание, что моя проблема не совсем связана с проблемами, которые решает AOP. Единственное, что меня беспокоит, так это то, что в AOP мой исходный код не является достаточным источником для прогнозирования поведения моей программы.

@mumtaz: я вижу, как это могло бы быть при применении аспектов ко всему пространству имен. Другой метод АОП: атрибуция методов / свойств / и т. Д. применить аспект (ы) к нему, идентично тому, что вы описываете.
Стивен Эверс

2

Я не специалист по AOP, но, читая об этом на протяжении многих лет, он всегда казался более слабой формой метапрограммирования, предлагаемой Lisp , особенно такими частями, как протокол метаобъектов.

Полагаю, это не должно вызывать удивления: Грегор Кичалес был одним из авторов AMOP, а позже написал AspectJ для Java!

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.