Аспектно-ориентированное слабое программирование?

Question

Есть ли какой-то серьезный недостаток аспектно-ориентированного программирования? Мне нравится идея смягчения сквозных проблем путем ограничения вызовов к одному классу внутри его аспекта. Но для меня это немного странно.

Вопрос 1. Давайте рассмотрим пример класса Logger. Каждому классу / методу может потребоваться вызвать некоторый метод класса Logger. Запись всех этих вызовов в аспекте Logger облегчает будущие изменения. Тем не менее, кто должен поддерживать аспект Logger? Если разработчик класса Logger делает это, он / она должен иметь глобальный взгляд на весь проект, что, на мой взгляд, невозможно, если проект достаточно большой. С другой стороны, если мы позволим всем изменять класс Logger, слишком много людей получат доступ к одному и тому же коду. И если кто-то из них допустит ошибку, код потерпит неудачу. Итак, в общем, кто должен поддерживать аспекты?

Вопрос 2. Будет ли производительность проблемой? Я думаю, что один pointcut похож на регистрацию одного слушателя событий. Если во время выполнения слишком много точек, будет ли это замедлять работу программы?

Спасибо

Answer 1

Вопрос 1

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

Вопрос 2

Возможно, представляет интерес .

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

Однако примите это к интерпретируемым языкам, и вы действительно действительно в «слушателе событий»стиль накладных расходов.

Слабые стороны

Я не эксперт, но я сделаю пару выводов и предложу любые дополнения:

• Отсутствие видимости.Не глядя на цель, какие аспекты влияют на нее, это может привести к трудностям отладки, особенно если это влияет на поток кода.Хорошая поддержка IDE, вероятно, могла бы облегчить это.
• Может привести к увеличению двоичных файлов при компиляции аспектов в код, хотя я думаю, что это незначительно.

Надеюсь, это поможет.