用AOP對设计模式进行改进.doc

用AspectJ增强设计模式上 设计模式长期以来一直是一些经验丰富的开发人员的工具箱的重要组成部分。不幸的是，因为模式可以影响多个类，所以它们也是侵入性的、难于使用（和重用）。本文是 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 如何使模式转变成可重用的基本方面，从而允许您下载预先构建好的模式库 —— 这是让模式爱好者们兴奋的一大优势。 1 为什么把 AOP 应用到设计模式？ ??? 我前面说过，许多模式都是横切的，当然我不是第一个想到这一点的人。最近有一篇研究论文对 GoF 模式进行了分析，分析发现：在 23 个模式中，有 17 个模式表现出某种程度的横切。（这篇论文是 Jan Hannemann 和 Gregor Kiczales 合著的“Java AspectJ 中的设计模式实现”，请参阅 参考资料 一节，以获取更多细节。） 如果 AOP 承诺可以协助解决横切，那么在设计模式上使用 AOP 有什么好处呢？我先从用通用术语回答这个问题开始，然后设置一个框架，通过它来考察每个设计模式。 ??? 在设计模式上使用 AOP 的好处 ??? AOP 第一个关键的好处是把指定设计模式的代码 本地化 的能力。这意味着通常只在一个方面或一对密切关联的方面上就可以实现模式。（这与 Java 语言实现形成对比，在 Java 语言实现中，模式应用程序可以分布在多个类中。）能够在一个地方看到所有代码会带来几个实际的好处。首先，如果模式的所有交互都能在一个地方看到的话，那么阅读代码的人就能更容易地理解模式。其次，如果开发人员需要改变模式的实现，那么他或她就能在一个地方修改模式，而不用在整个系统中追踪模式的片断。最后，开发人员可以用有意义的名称描述封装模式的方面，为以后的维护人员提供有关模式意图的文字线索。例如，可以把方面命名为 SensorAdapt