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

Question

Каковы возможные и критические недостатки аспектно-ориентированного программирования?

Например: загадочная отладка для новичков (влияние читабельности)

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

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

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

Answer 3

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

Answer 4

• Плохая поддержка набора инструментов - отладчики, профилировщики и т. Д. Могут не знать о AOP и поэтому могут работать с кодом, как если бы все аспекты были заменены процедурным кодом
• Раздувание кода - небольшой исходный код может привести к гораздо большему объектному коду, так как код «переплетается» по всей базе кода

Answer 5

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

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

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

Answer 6

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

Answer 7

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

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

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