设计模式-总体介绍

1 总体介绍

1.1 什么是设计模式

每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动。- Christopher Alexander

对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述。- GoF

四个基本要素：

模式名称（pattern name） 一个助记名，它用一两个词来描述模式的问题、解决方案和效果。命名一个新的模式增加了我们的设计词汇。设计模式允许我们在较高的抽象层次上进行设计。基于一个模式词汇表，我们自己以及同事之间就可以讨论模式并在编写文档时使用它们。模式名可以帮助我们思考，便于我们与其他人交流设计思想及设计结果。找到恰当的模式名也是我们设计模式编目工作的难点之一。
问题(problem) 描述了应该在何时使用模式。它解释了设计问题和问题存在的前因后果，它可能描述了特定的设计问题，如怎样用对象表示算法等。也可能描述了导致不灵活设计的类或对象结构。有时候，问题部分会包括使用模式必须满足的一系列先决条件。
解决方案(solution) 描述了设计的组成成分，它们之间的相互关系及各自的职责和协作方式。因为模式就像一个模板，可应用于多种不同场合，所以解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合（类或对象组合）来解决这个问题。
效果(consequences) 描述了模式应用的效果及使用模式应权衡的问题。尽管我们描述设计决策时，并不总提到模式效果，但它们对于评价设计选择和理解使用模式的代价及好处具有重要意义。软件效果大多关注对时间和空间的衡量，它们也表述了语言和实现问题。因为复用是面向对象设计的要素之一，所以模式效果包括它对系统的灵活性、扩充性或可移植性的影响，显式地列出这些效果对理解和评价这些模式很有帮助。

1.2 描述设计模式

模式名和分类模式名简洁地描述了模式的本质。
意图是回答下列问题的简单陈述：设计模式是做什么的？它的基本原理和意图是什么？它解决的是什么样的特定设计问题？
别名模式的其他名称。
动机用以说明一个设计问题以及如何用模式中的类、对象来解决该问题的特定情景。
适用性什么情况下可以使用该设计模式？该模式可用来改进哪些不良设计？你怎样识别这些情况？
结构采用基于对象建模技术的表示法对模式中的类进行图形描述。
参与者指设计模式中的类和/或对象以及它们各自的职责。
协作模式的参与者怎样协作以实现它们的职责。
效果模式怎样支持它的目标？使用模式的效果和所需做的权衡取舍？系统结构的哪些方面可以独立改变？
实现实现模式时需要知道的一些提示、技术要点及应避免的缺陷，以及是否存在某些特定于实现语言的问题。
代码示例实现该模式的代码片段。
已知应用实际系统中发现的模式的例子。
相关模式与这个模式紧密相关的模式有哪些？其间重要的不同之处是什么？这个模式应与哪些其他模式一起使用？

1.3 设计模式怎样解决设计问题

寻找合适的对象
决定对象的粒度
指定对象接口
描述对象的实现
运用复用机制
关联运行时刻和编译时刻
设计应支持变化

1.4 导致重新设计的一般原因，以及解决这些问题的设计模式

通过显式地指定一个类来创建对象在创建对象时指定类名将使你受特定实现的约束而不是特定接口的约束。这会使未来的变化更复杂。要避免这种情况，应该间接地创建对象。
设计模式：Abstract Factory， Factory Method，Prototype。
对特殊操作的依赖 当你为请求指定一个特殊的操作时，完成该请求的方式就固定下来了。为避免把请求代码写死，你将可以在编译时刻或运行时刻很方便地改变响应请求的方法。
设计模式：Chain of Resposibility，Command。
对硬件和软件平台的依赖 外部的操作系统接口和应用编程接口(API)在不同的软硬件平台上是不同的。依赖于特定平台的软件将很难移植到其他平台上，甚至都很难跟上本地平台的更新。所以设计系统时限制其平台相关性就很重要了。
设计模式：Abstract Factory， Bridge。
对对象表示或实现的依赖知道对象怎样表示、保存、定位或实现的客户在对象发生变化时可能也需要变化。对客户隐藏这些信息能阻止连锁变化。
设计模式：Abstract Factory，Bridge，Memento，Proxy
算法依赖 算法在开发和复用时常常被扩展、优化和替代。依赖于某个特定算法的对象在算法发生变化时不得不变化。因此有可能发生变化的算法应该被孤立起来。
设计模式：Builder，Iterator，Strategy，Template Method，Visitor
紧耦合 紧耦合的类很难独立地被复用，因为它们是互相依赖的。紧耦合产生单块的系统，要改变或删掉一个类，你必须理解和改变其他许多类。这样的系统是一个很难学习、移植和维护的密集体。松散耦合提高了一个类本身被复用的可能性，并且系统更易于学习、移植、修改和扩展。设计模式使用抽象耦合和分层技术来提高系统的松散耦合性。
设计模式：Abstract Factory，Command，Facade，Mediator，Observer，Chain of Responsibility。
通过生成子类来扩充功能 通常很难通过定义子类来定制对象。每一个新类都有固定的实现开销(初始化、终止处理等 )。定义子类还需要对父类有深入的了解。如，重定义一个操作可能需要重定义其他操作。一个被重定义的操作可能需要调用继承下来的操作。并且子类方法会导致类爆炸，因为即使对于一个简单的扩充，你也不得不引入许多新的子类。一般的对象组合技术和具体的委托技术，是继承之外组合对象行为的另一种灵活方法。新的功能可以通过以新的方式组合已有对象，而不是通过定义已存在类的子类的方式加到应用中去。另一方面，过多使用对象组合会使设计难于理解。许多设计模式产生的设计中，你可以定义一个子类，且将它的实例和已存在实例进行组合来引入定制的功能。
设计模式：Bridge，Chain of Responsibility，Composite，Decorator，Observer，Strategy。
不能方便地对类进行修改 有时你不得不改变一个难以修改的类。也许你需要源代码而又没有(对于商业类库就有这种情况 )，或者可能对类的任何改变会要求修改许多已存在的其他子类。设计模式提供在这些情况下对类进行修改的方法。
设计模式：Adapter，Decorator，Visitor。

1.5 怎样选择设计模式

考虑设计模式是怎样解决设计问题的
浏览模式的意图部分
研究模式怎样互相关联
研究目的相似的模式
检查重新设计的原因
考虑你的设计中哪些是可变的

1.6 怎样使用设计模式

大致浏览一遍模式特别注意其适用性部分和效果部分，确定它适合你的问题。
回头研究结构部分、参与者部分和协作部分确保你理解这个模式的类和对象以及它们是怎样关联的。
看代码示例部分，看看这个模式代码形式的具体例子研究代码将有助于你实现模式。
选择模式参与者的名字，使它们在应用上下文中有意义设计模式参与者的名字通常过于抽象而不会直接出现在应用中。然而，将参与者的名字和应用中出现的名字合并起来是很有用的。这会帮助你在实现中更显式的体现出模式来。例如，如果你在文本组合算法中使用了 Strategy 模式，那么你可能有名为 SimpleLayout Strategy 或 TeX Layout Strategy 这样的类。
定义类声明它们的接口，建立它们的继承关系，定义代表数据和对象引用的实例变量。识别模式会影响到的你的应用中存在的类，做出相应的修改。
定义模式中专用于应用的操作名称这里再一次体现出，名字一般依赖于应用。使用与每一个操作相关联的责任和协作作为指导。还有，你的名字约定要一致。例如，可以使用“Create-”前缀统一标记 Factory 方法。
实现执行模式中责任和协作的操作实现部分提供线索指导你进行实现。代码示例部分的例子也能提供帮助。

2 目录

按目的准则（即模式是用来完成什么工作）分类：
注：第二个（）表示范围准则，指定模式主要是用于类还是用于对象。类模式处理类和子类之间的关系，这些关系通过继承建立，是静态的，在编译时刻便确定下来了。对象模式处理对象间的关系，这些关系在运行时刻是可以变化的，更具动态性。从某种意义上来说，几乎所有模式都使用继承机制，所以“类模式”只指那些集中于处理类间关系的模式，而大部分模式都属于对象模式的范畴。