Мне задали этот вопрос в интервью. Я четко знаю, что такое узор декоратора и как его можно использовать. Но я не смог продумать этот вопрос в интервью.
Это актуальный вопрос.
Является ли AOP изменением шаблона декоратора? Как реализация АОП отличается от шаблона декоратора торговой марки?
Я бы сказал, AOP (Аспектно-ориентированное программирование) не является шаблоном сам по себе (и, следовательно, не является типом рисунка декоратора из моего POV)... его реализация может быть сделано с помощью одного или нескольких шаблонов (включая использование рисунка декоратора)... AOP - парадигма программирования IMHO - другие парадигмы - это, например, ООП, функциональное программирование или процедурное программирование...
Я согласен с Яхией в целом. Обратите внимание, что, хотя аспекты добавляют и, возможно, изменяют существующую функциональность, они обычно применяются ко всем методам или классам, а не к отдельным экземплярам.
Я бы сказал, да, AOP - это реализация шаблона декоратора.
Для меня самые большие различия были в том, как он реализован и как он применяется.
Традиционные декораторы обычно представляют собой объекты, которые либо объединяют объект, который оформляется явно, либо активируются точкой расширения базового объекта.
AOP обычно указывается более "декларативным" способом - традиционные декораторы являются общей частью кода основной линии.
Традиционные декораторы обычно применимы только к определенным классам или интерфейсам и обычно применяются на уровне экземпляра. АОП (в общем) может обернуть функциональность вокруг практически произвольного кода на "уровне земли" - поведение будет распространяться на все экземпляры того, к чему применяется этот аспект. Это то, что позволяет ему удовлетворять свои требования о "сквозной функциональности": это не обязательно ограничивается узкой областью, как декораторы.
Это зависит от основного языка, однако - некоторые из них более гибкие, чем другие. Вышеизложенное относится больше к "статическим" языкам (например, Java) и не столько к языку, как Ruby, где то, что выглядит как традиционный декоратор, может быть применено к одному экземпляру или стать частью определения класса.
Кроме того, каркасы инъекций зависимостей, которые поддерживают перехват для сквозных проблем, в основном применяют узор декоратора под капотом. Рамки, которые переносят аспекты на промежуточный язык (как в .Net MSIL), не зависят от интерфейсов или наследования, в отличие от шаблона декоратора.