Каковы недостатки Аспектно-ориентированного программирования (АОП)?

Ответ 1

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

Ответ 2

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

Например, шаблон factory, очевидно, является чем-то, что AOP может сделать лучше, поскольку DI также может сделать это хорошо, но шаблон наблюдателя проще при использовании AOP, как и шаблон стратегии.

Это будет сложнее unit test, esp, если вы выполняете переплетение во время выполнения.

Если соткать во время выполнения, вы также получаете удар производительности.

Хороший способ моделировать то, что происходит при смешивании AOP с классами, является проблемой, поскольку UML я не думаю, что это хорошая модель в этот момент.

Если вы не используете Eclipse, тогда у инструментов есть проблемы, но с Eclipse и AJDT AOP намного проще.

Мы по-прежнему используем junit и nunit, и поэтому нам нужно изменить наш код, чтобы можно было запускать единичные тесты, при использовании привилегированного режима AOP мог бы улучшить тесты модулей, также проверив частные методы, и нам не нужно менять наши программы, чтобы заставить их работать с модульным тестированием. Это еще один пример того, что вы не понимаете, насколько AOP может быть полезным, мы все еще привязаны во многих отношениях к прошлому с помощью фреймворков с единичным тестированием и текущих реализаций шаблонов проектирования и не видим, как АОП может помочь нам улучшить кодирование.

Ответ 3

Я думаю, что самая большая проблема заключается в том, что никто не знает, как определить семантику аспект, или как объявлять точки соединения непроцедурными.

Если вы не можете определить, какой аспект выполняется независимо от контекста, в который он будет встроен, или определить эффекты, которые он имеет таким образом, чтобы он не повредил контекст, в который он встроен, вы (и инструменты) не могут рассуждать о том, что он делает надежно. (Вы заметите, что наиболее распространенным примером аспектов является "ведение журнала", которое определяется как "записывать некоторые материалы в поток журнала, о котором приложение ничего не знает", потому что это довольно безопасно). Это нарушает ключевое понятие Дэвида Парна о скрытии информации. Один из худших примеров аспектов, которые я вижу, это те, которые вставляют примитивы синхронизации в код; это влияет на последовательность возможных взаимодействий, которые может иметь код. Как вы можете знать, что это безопасно (не будет ли "тупик", который не будет "жить", не будет защищать? Восстанавливается перед лицом брошенного исключения в партнере синхронизации?), Если только приложение уже делает тривиальные вещи уже.

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

Итак, аспекты - это интересная идея, но я думаю, что они технологически незрелые. И эта незрелость делает их использование хрупким. И это там, где проблема. (Я большой поклонник автоматизированных средств разработки программного обеспечения [см. Мою биографию] просто не так).

Ответ 4

Обслуживание и отладка. С aop вы внезапно получаете код, который выполняется в данной точке (ввод метода, выход, независимо), но просто глядя на код, вы не знаете, что он даже вызван, особенно если конфигурация aop находится в другом файле, как xml config. Если советы приводят к некоторым изменениям, то при отладке приложения все может выглядеть странно без объяснения причин. Это не влияет только на новичков.

Ответ 5

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

Мы используем блок инъекции политики в EntLib 4.1 довольно широко, а также Unity для DI, и это просто не то, что быстро утекает для некоторых людей. Я нахожу, что сам объясняю снова и снова тем же людям, почему приложение не ведет себя так, как они ожидают. Обычно они начинают объяснять что-то, и я говорю "см. Эту декларацию выше метода".:) Некоторые люди сразу это понимают, любят и становятся чрезвычайно продуктивными - другие борются.

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

Ответ 6

Что касается аргумента обслуживания/отладки, аспектно-ориентированное программирование имеет тенденцию идти рука об руку со всеми другими аспектами гибких программных разработок.

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

Кроме того, может быть намного проще поддерживать небольшой, понятный код с советами, чем большой, непонятный код footprint без советов (совет - это то, что превращает большой, непонятный код в небольшой, четкий код след).

Ответ 7

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