Является ли АОП типом шаблона декоратора?

Question

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

Это действительно заданный вопрос.

Является ли AOP разновидностью шаблона декоратора?Как реализация AOP отличается от шаблона оформления товарного знака?

Answer 1

Я бы сказал, AOP (Аспектно-ориентированное программирование) НЕ является шаблоном сам по себе (и, следовательно, не является типом шаблона декоратора из моего POV) ... его реализация может быть выполнена с помощью одного или нескольких шаблонов (включая использование шаблона декоратора ) ... AOP - это парадигма программирования ИМХО - другие парадигмы, например, ООП, функциональное программирование или процедурное программирование ...

Answer 2

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

Answer 3

Я бы сказал в некотором смысле, да, AOP - это реализация шаблона декоратора.

Для меня самые большие различия были бы в том, как он реализован и как он применяется.

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

AOP обычно указывается более «декларативным» образом - традиционные декораторы являются общей частью основного кода.

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

Однако это зависит от базового языка - некоторые являются более гибкимичем другие.Вышесказанное относится больше к «статическим» языкам (например, Java), а не к языку, подобному Ruby, где то, что выглядит как традиционный декоратор, может быть применено к одному экземпляру или стать частью определения класса.

Answer 4

Кроме того, структуры внедрения зависимостей, которые поддерживают перехват для сквозных задач, в основном применяют шаблон декоратора под капотом. Фреймворки, которые вплетают аспекты в промежуточный язык (как в .Net MSIL), не зависят от интерфейсов или наследования в отличие от шаблона декоратора.