【IT168技术文档】

    设计模式长期以来一直是一些经验丰富的开发人员的工具箱的重要组成部分。不幸的是，因为模式可以影响多个类，所以它们也是侵入性的、难于使用（和重用）。本文是 AOP@Work 系列的第 3 部分，是一篇由两部分组成的文章，在这篇文章中，Nicholas Lesiecki 将介绍 AOP 是怎样通过根本转变模式实现来解决这一问题的。他研究了三个经典的 Gof 设计模式 （适配器模式、修饰器模式和观察者模式），同时还将讨论使用面向方面技术实现这些模式所带来的实践和设计方面的好处。

    什么是设计模式？根据 Design Patterns: Elements of Reusable Object-Oriented Software：

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

    在多年成功地应用模式解决 OO 系统中的问题之后，我发现自己也认同了这个定义。模式是与普通程序员谈论设计的最好方式，它们代表解决“重复出现的设计问题”的非常好的实践。所以，当我参加了 Stuart Halloway 的一次访谈时，我感到有点震惊：他为 GoF 提供了另一个头衔：“处理 C++ 中破损事物的修理厂”。他的观点是：在一种语言中以“模式”方式存在的东西，在不同的范式下，可以融入语言本身。接着他给出了 Factories 的示例 —— 该示例在 Java 语言中有用，但在 Objective-C 中却没多大用，后者支持从构造函数中返回子类型。
 
    我思考了很长一段时间，然后我认识到两个方面实际上说的是同一件事之前：设计模式提供了表达那些无法直接在编程语言中表达的概念的词汇表。

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

    本文的目的是探索用 AOP （特别是用 AspectJ）进行的模式实现。我选择 GoF 模式，是因为它是一个非常流行和通用的工具。在本文的第 1 部分中，我要设置一些分析模式影响的指标，然后研究适配器和修饰器模式。适配器会演示静态交叉的优势，而修饰器则会暴露它自身是一个正在消失的模式。在 第 2 部分中，我将提供对观察者模式更加深入的研究，这种模式并没有消失，但您会看到在用 AspectJ 实现它时的一些主要好处。第 2 部分将显示 AspectJ 如何使模式转变成可重用的基本方面，从而允许您下载预先构建好的模式库 —— 这是让模式爱好者们兴奋的一大优势。