【发布时间】：2011-12-28 01:36:14
【问题描述】：
我在一次采访中被问到这个问题。我清楚地知道装饰器模式是什么以及如何使用它。但是我在采访中没能想通这个问题。
这是实际提出的问题。
AOP 是装饰器模式的变体吗？ AOP 实现与商标装饰器模式有何不同？
【问题讨论】：
标签： design-patterns language-agnostic aop decorator
【发布时间】：2011-12-28 01:36:14
【问题描述】：
我会说AOP (Aspect Oriented Programming) 本身不是一种模式（因此不是我 POV 中的一种装饰器模式）...它的实现可以通过一个或多个模式完成（包括使用 decorator pattern） ... AOP 是 programming paradigm 恕我直言 - 其他范式例如 OOP、函数式编程或过程式编程...
【讨论】：
-
AOP 实现主要使用代理和装饰器的混合。
-
AOP的语义是在语言层面上操作的：添加关键字、改变控制流等；而 Decorator 完全在 OOP 的语义中运行（只是覆盖虚拟方法）。这使得 Decorator 成为一种模式，而 AOP 则被限定为“语言扩展”。
-
@rwong 这取决于它是用什么语言实现的，例如，对于 AspectJ，是的。对于更动态的语言，它可以只是一个库。
我总体上同意 Yahia。请注意，虽然方面添加并可能修改现有功能，但它们通常应用于整个方法或类，而不是单个实例。
【讨论】：
-
+1 用于突出显示“整个方法/类与单个实例”这一点:-)
我会说，是的，AOP 是装饰器模式的一种实现。
对我来说，最大的不同在于它的实现方式和应用方式。
传统的装饰器通常是组合被显式装饰的对象或由底层对象的扩展点启用的对象。
AOP 通常以更“声明性”的方式指定——传统的装饰器通常是主线代码的一部分（与注释、配置文件或某种形式的已配置字节码操作系统相反）。
传统的装饰器一般只适用于特定的类或接口，一般应用在实例级别。 AOP（通常）可以在“底层”将功能包装在基本上任意代码周围——行为将扩展到 all 应用方面的任何实例。这就是它能够满足其“横切功能”要求的原因：它不一定限于像装饰器那样狭窄的范围。
这取决于底层语言，不过，有些语言比其他语言更灵活。以上内容更多地适用于“静态”语言（例如，Java），而不是像 Ruby 这样的语言，在这种语言中，看起来像传统装饰器的东西可以应用于单个实例，或者成为类定义的一部分。
【讨论】：
此外，支持拦截横切关注点的依赖注入框架基本上在底层应用了装饰器模式。将方面编织到中间语言中的框架（如在 .Net MSIL 中）不依赖于接口或继承，这与装饰器模式不同。
【讨论】：