为什么把 AOP 应用到设计模式？

    我前面说过，许多模式都是横切的，当然我不是第一个想到这一点的人。最近有一篇研究论文对 GoF 模式进行了分析，分析发现：在 23 个模式中，有 17 个模式表现出某种程度的横切。（这篇论文是 Jan Hannemann 和 Gregor Kiczales 合著的“Java AspectJ 中的设计模式实现”，请参阅 参考资料 一节，以获取更多细节。） 如果 AOP 承诺可以协助解决横切，那么在设计模式上使用 AOP 有什么好处呢？我先从用通用术语回答这个问题开始，然后设置一个框架，通过它来考察每个设计模式。

    在设计模式上使用 AOP 的好处

    AOP 第一个关键的好处是把指定设计模式的代码 本地化 的能力。这意味着通常只在一个方面或一对密切关联的方面上就可以实现模式。（这与 Java 语言实现形成对比，在 Java 语言实现中，模式应用程序可以分布在多个类中。）能够在一个地方看到所有代码会带来几个实际的好处。首先，如果模式的所有交互都能在一个地方看到的话，那么阅读代码的人就能更容易地理解模式。其次，如果开发人员需要改变模式的实现，那么他或她就能在一个地方修改模式，而不用在整个系统中追踪模式的片断。最后，开发人员可以用有意义的名称描述封装模式的方面，为以后的维护人员提供有关模式意图的文字线索。例如，可以把方面命名为 SensorAdapter，这表明在传感器上使用的是适配器模式。

    AspectJ 模式实现的另一个关键好处就是 遗忘性（obliviousness）。换句话说，在模式中发挥作用的类不必知道这个角色。这个好处直接来自本地化 —— 因为模式是在某一个方面实现本地化的，所以不需要冒犯其参与者。遗忘性让模式参与者更容易理解代码。不仅如此，遗忘性还让模式更容易组合。在 Java 语言实现中，如果类参与到多个模式中，模式的机制会迅速模糊它的核心含义。如果类不知道那些在模式中的参与者，那么可以在其他上下文中重用这些类。在本文的 第 2 部分 中将看到这方面的一个具体示例。

    这些好处允许对某些模式实现代码级重用。设计模式的概念和结构一直都是可重用的。如果想实现观察者模式，任何人都可以找出 GoF 的书籍，把模式应用到自己的代码中。但是，如果使用面向方面技术，那么通过下载 ObserverProtocol 方面 （可以在设计模式计划中获得它，请参阅参考资料 一节），就可以避免这个麻烦。除了节省的实现工作之外，代码级重用还允许模式代码和文档进行更紧密的耦合。例如，我可以浏览 ObserverProtocol 的 javadoc，不用另找一本书就可以理解它的意图和结构。

    分析框架

    每个模式的描述都跟着一个公共结构。我将从一个示例问题开始介绍，提供对这个模式的通用描述。然后我会描述如何实现这个模式，先使用 Java 语言实现它，然后使用 AspectJ 语言实现它。在每个实现后面，我都会描述是什么造成了模式的横切，以及这个版本的模式在理解、维护、重用和编排代码的时候有什么效果。