适配器模式

设计模式系统地命名、促进和解释了解决面向对象系统中重复出现的设计问题的一个通用设计。它描述了问题、解决方案、何时应用该解决方案以及所产生的结果。它还提供了一些实现提示和示例。解决方案是解决问题的对象和类的总体安排。可以定制并实现解决方案，解决具体上下文环境中的问题。 

我思考了很长一段时间，然后我认识到两个方面实际上说的是同一件事之前：设计模式提供了表达那些无法直接在编程语言中表达的概念的词汇表。

那么，AOP 位居何处呢？对于 OOP，我们有 GoF 模式，它提供了处理公共的概念（像观察者和修饰器）的统一方法（尽管有时有点麻烦）。AOP 构建在 OOP 之上，提供了表达横切关注点的直接方式。它认为某些 GoF 模式是关于横切的，可以直接用 AOP 表示。所以您会注意到，对于一些包含许多类的模式，用一个方面就可以表达。有些模式变得更易使用，因为它们可以包含更少代码。有些模式得到了非常好的支持，以致于它们几乎消失不见。其他模式严格绑定到 OOP （例如处理类结构的模式），所以它们在与 AOP 结合使用的时候保持不动。

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

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

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

适配器模式

我要详细考虑的第一个模式就是适配器模式。适配器模式完全是关于兼容性的。这个模式允许类与其他原来由于接口不兼容而无法交互的类进行交互。要在 Java 代码中实现适配器，需要用特殊的适配器类包装目标类，适配器类能把目标类的 API 转换成客户想要的 API，或者转换成能够更容易利用的 API。