《设计模式展望.doc》由会员分享，可在线阅读，更多相关《设计模式展望.doc（5页珍藏版）》请在三一文库上搜索。
1、第11章 设计模式展望本书讲解了设计模式，同时也介绍了C#3.0这一现代编程语言的一些高级特性。在很多时候，我们都会发现语言对模式的实现提供了大量帮助。在最后这一章，我们将回顾一下这些模式以及它们所需要的语言特性，然后展望一下研究人员正在为语言的下一轮迭代准备什么东西。模式总结现在是作一下总结的时候了，我们将总结本书中所有的设计模式以及用于实现它们的语言特性。有必要重复一下：在某些情形中，本书中的模式实现跟基于Java、C+或早期版本的C#语言的传统实现形式相比，有很大的差别。因此，你应该把表11-1的“语言特性”一栏理解为“现代的、适当的、合乎需要的”，而不是“固定的、标准的、唯一的”。这个
2、表格对本书中所有的理论代码作了一次有用的比较，你也可以在本书的网站上（http:/patterns.cs.up.ac.za）找到这些代码。第四栏中斜体的语言特性是用在其它的可选实现方案或示例代码中的，它们在基本的理论代码中没有用到。大多数语言特性都以复数形式给出（原作者在列举语言特性时，使用的都是英文单词的复数形式，译者注），但实际使用时可能只用到某种特性的单个实例，这取决于系统的尺寸。这一表格是按照语言特性的难易程度排列的，因此你可以得到哪种模式基于语言知识更易实现的直观感觉；但是，不要把这一标准跟模式本身的难易相混淆。我个人的经验是，出现在表格上半部分的适配器（Adapter）和访问者（V
3、isitor）模式，是两种实现起来颇具挑战性的模式。其难点主要在于类型之间的相互作用，因为这两种模式的目标都是类型解耦。在C#这种提供严格类型检查的语言中，即使不考虑泛型，也需要相当细心才能确保参数和对象实例的正确匹配。表11-1 模式和语言特性总结（第二栏为译者加，以方便对照）模式模式（英文）语言特性可选的和示例中使用的抽象工厂Abstract Factory接口泛型、泛型约束 桥接Bridge接口扩展方法生成器Builder接口泛型、泛型约束装饰器Decorator接口工厂方法Factory Method接口适配器Adapter接口、继承委托、匿名函数、线程、事件代理Proxy接口、私有访
4、问集合类状态State接口、选择语句策略Strategy接口、选择语句泛型、可空类型解释器Interpreter递归、选择语句访问者Visitor接口、递归反射外观Facade命名空间单例Singleton私有访问、嵌套类、静态属性模板方法Template Method方法重写命令Command委托中介Mediator委托线程观察者Observer接口、委托、事件线程享元Flyweight接口、结构、集合类、索引器隐式类型推导、初始化式、匿名类型备忘录Memento序列化、集合类、索引器原型Prototype克隆、序列化、集合类、索引器责任链Chain of Responsibility泛型、
5、异常枚举类型、初始化式组合Composite接口、集合类、泛型、属性 迭代器Iterator枚举器、foreach、查询表达式 (Linq)泛型、递归另外一种考查模式的方式是分析它们与哪些模式交互，或者它们支持哪些模式。表11-2从这一角度给出了一些模式分组的思想，尽管带有一点主观性。表11-2 模式交互模式与其交互或被其支持的模式抽象工厂桥接, 工厂方法, 原型, 单例适配器桥接抽象工厂生成器组合责任链组合命令备忘录, 组合组合生成器, 装饰器, 享元, 解释器, 访问者, 责任链, 命令, 迭代器装饰器组合, 策略外观单例工厂方法抽象工厂, 模板方法享元组合, 解释器, 策略, 状态解释器
6、组合, 享元, 访问者迭代器访问者, 备忘录, 组合中介观察者备忘录迭代器, 命令观察者中介原型抽象工厂代理单例外观, 抽象工厂状态享元策略装饰器, 享元, 模板方法模板方法工厂方法, 策略访问者迭代器, 组合, 解释器跟其它模式交互最多的是那些创建和管理复杂结构的模式，比如组合（Composite）、享元（Flyweight）和抽象工厂（Abstract Factory），这并不令人奇怪。当有多种类型需要处理的时候，许多其它的模式也依赖这些模式。表中适配器（Adapter）和代理（Proxy）模式没有列出与其交互的模式，但不要忘了这种两种模式也是来自于相互关联的多个设计。本书的特点之一是对每
7、一种模式都给出了实例演示。也有一些示例被用在多个模式中，从而演示了上面所描述的模式交互。通过这种方式，我们可以在多样性和连续性之间尽量保持平衡。在许多练习中，我建议使用其它模式对示例进行改编。特别的，单例（Singleton）模式在本书中没有被大量使用，而它是一个很适合被应用到已有程序的模式。为方便引用，表11-3列举了本书所使用的示例以及使用它们的模式。表11-3 演示模式的示例Example博客观察者聊天室中介课程成绩评估访问者、解释器家族树迭代器Gucci 和Poochy (产品制造)抽象工厂、生成器菜单系统命令Mirrors解释器相片装饰器、相片库、相片组、相片集合装饰器、组合、享元、
8、外观、原型、适配器RCP游戏、Tic-Tac-Toe游戏状态、备忘录海鸟飞机适配器排序演示器策略、模板方法鳄梨采购工厂方法SpaceBook、Openbook、Coolbook代理、桥接、适配器Trusty Bank责任链练习总结和制表是从诸多模式中理出头绪的有效方法。你可以尝试下面两个任务：1.制作一个模式表格，分别用一句话描述每种模式的任务；2.制作一个模式表格，列举每种模式的参与者，每种模式不必超过4种（不能重复，不考虑Client）。设计模式展望我将通过一些跟设计模式及其发展方向有关的结论来结束本书。我们已经看到，设计模式是一种形式化的机制，这种机制以文档的形式总结了常见软件设计问题的
9、解决方案。1977年，Christopher Alexander在民用建筑（civil architecture）中首次提出了设计模式的概念；它们后来被改编到软件设计中。在过去的几年里，设计模式在学术和商业领域的影响都获得了显著提高，而且大量的研究者对设计模式进行了分类研究。设计模式通常被看作软件设计问题的解决方案。它们当然不是软件设计的唯一解决方案，而且它们也不应该被用来排斥其它方案。基于组件的设计、软件架构、面向方面编程以及重构，这些在软件设计中都具有同样重要的地位。从软件工程的大背景来看，可以认为，设计模式也提出了如下一些来自模式自身的挑战：可跟踪性（Traceability）如果编程语
10、言提供的支持很少，设计模式的可跟踪性将难以保证。在一种编程语言中，某个设计模式的逻辑实现可能被分散到很多类中，导致难以跟踪。从这方面来看，通过使用C#语言的一些更加简洁的特性，比如委托和查询表达式，本书中的实现已经取得了很大的进步。可重用性（Reusability）设计模式在软件系统的设计中被使用并重用，但来自语言的支持却很少，开发者必需通过一种编程语言一遍又一遍地实现模式。基于组件的开发可以封装行为并直接重用，而设计模式并不能向开发者提供同样的便利。可编码性（Writability）设计模式中有很多方法的行为非常简单。如果没有好的编程工具，编写和维护这些代码非常乏味。再一次，使用更加简洁和强
11、大的语言特性可以减轻程序员的负担。可维护性（Maintainability）使用多种模式会导致出现大量相互依赖的类。而使用传统面向对象编程语言的时候，相互依赖的类则可能引发维护问题。最新的研究中，人们正在考虑如何将设计模式转换成可重用的实体，从而开发者不必反复地实现同一种模式。在1997年，Bertrand Meyer将可重用性定义为“软件元素可用于构造多种不同应用的能力”。在设计模式的上下文中，一种特定的语言特性、一种语言的库或者一个组件都可以用于解决模式实现的可重用性问题。Meyer继续指出，“如果能实现一个可重用的组件来提供一个模式所需的所有功能”，那么这种设计模式“就是可组件化的”，他
12、还指出，“一个成功的模式不应该仅仅是书面描述，它必需是一个软件组件，或者一套组件。”这一工作仍在进行中。通过本书我们还看到，语言一直在向前演化。迭代器（Iterator）模式现在被C# 3.0全面支持，直接支持单例（Singleton）模式的可行思路也存在了。后面还可能有其它的模式被支持，模式和语言的集成是一个硕果累累的研究领域。结束语本书带你走过了23种设计模式（有的还带有额外的变种），25个C#语言特性，20个示例和25段理论代码。现在，在C#3.0中，你应该能够从设计模式中受益了。设计模式能在以下方面带来很多好处：*提高设计的可重用性；*提供一组公共的词汇，便于项目组内部或项目组之间进行交流；*便于文档撰写；*帮助开发者对系统进行重新组织，不管系统之前是否使用过设计模式；*直接学习到老程序员从长期经验中领悟出的知识；*协助新员工培训；*超越“以编程语言为中心”的观点；*最大限度地开发利用编程语言的功能。在以前的编程生涯中，你可能还有没有体会到这种设计所带来的好处，当然，除了最后一个，因为它正是这本书的主题。现在，你已经具备了本书提供的知识和技能，你将能够为每一种设计模式选择正确的使用时机和正确的使用场合，并确信自己可以写出正确的代码。