基于设计模式的认识与理解
摘要：本文从设计模式的起源开始介绍，通过对五种具体常用的设计模式的详细介绍和分析来让读者更加具体形象的了解设计模式并学会在实际工作中应用它们。
关键字：设计模式通用结构图接口
1 引言
设计模式源自建筑学和人类学，设计模式是面向对象技术的最新进展之一。
现在面向对象分析工具、图书和培训都在加入设计模式的内容，设计模式学习小组在各地的发展如火如荼。
通常的建议，都是在掌握了基本面向对象技术之后，再学习设计模式。
但在学习面向对象技术过程中较早地学习设计模式，对于加深面向对象分析与设计的理解大有裨益。
2设计模式的类型
设计模式总共可以分为三种类型：创建型模式、结构型模式、行为型模式。
2.1 创建型设计模式
创建型设计模式即以灵活的方式创建对象的集合，有助于我们设计包含对象集的应用程序：允许我们从单一的代码块中创建几个可能的集合，但是必须具备如下的属性：
（1）在运行时可以创建集合的多个版本。
（2）约束创建的对象：例如，确保类只有一个实例。
创建型设计模式主要包括：Factory设计模式、Abstract Factory设计模式、Prototype（原型）设计模式、Singleton（单态）模式。
2.2 结构型设计模式
结构型设计模式即代表相关对象的集合，有助于我们以链表或树的形式来安排对象集合。
结构型设计模式主要包括：Composite（复合）设计模式、Decorator（装饰者）设计模式、Adapter （适配器）设计模式、Façade设计模式、Flyweight（享元）设计模式、Proxy（代理）设计模式。
2.3 行为型设计模式
行为型设计模式即在对象中捕获行为。
行为型设计模式主要包括：Chain of Responsibility(职责链)设计模式、Command（指令）设计模式、Interpreter（解释器）设计模式、Mediator（中介者）设计模式、Observer（观察者）设计模式、State（状态）设计模式、Template（模板）设计模式。
3 设计模式的种类
设计模式总共分为三大类：创建模型、结构模型、行为模型。
细分的话总共有23种设计模式。
以下是对几种模式的介绍。
3.1 Facade模式
Facade模式的意图是为子系统中的一组接口提供一个统一接口。
这个模式定义了一个更高层的接口，使子系统更加容易使用！
Facade模式简化了对所需子系统的使用过程。
但是，由于Facade并不完整，因此客户可能无法使用某些功能。
实现的步骤分两步：第一步,定义一个（或多个）具备所需接口的新类。
第二步，让新的类使用原有的系统。
图3-1 Façade 模式的通用结构图
Facade 模式可以应用于：
（1） 不需要使用一个复杂系统的所有功能，而且可以创建一个新的类，包含访问系统的所有规
则。
如果只需要使用系统的部分功能，那么你为新类所创建的API 将比原系统的API 简单的多。
（2
） 希望封装或者隐藏原系统。
（3） 希望使用原系统的功能，而且还希望增加一些新的功能。
（4） 编写新类的成本小于所有人学会使用或者未来维护原系统上所需的成本。
3.2 Adapter 模式
Adapter 模式的意图是将一个类的借口转换成客户希望的另一个接口。
这种模式使原本由于接口不兼容而不能一起工作的类可以一起工作。
图3-2 Adapter 模式的通用结构图
Facade 模式与Adapter 模式的比较： （1） 在两个模式中，都存在既有的类。
（2）在Facade 模式中，我无须按某个接口进行设计；而在Adapter 模式中，则必须按某个接口进
行设计。
（3）在Facade模式中不需要多态行为，而在Adapter模式中多态行为可能是需要的。
在某些时候，如果只能按特定接口进行设计，那么就必须使用Adapter模式。
（4）Façade模式中的动机是简化接口。
而在Adapter模式中，尽管也是越简单越好，但是设计必须遵循一个已有的接口，不能简化任何东西，即使可能存在更简单的接口。
（5）Facade模式与Adapter模式之间的另一个差异，就是Facade隐藏了多个类，而Adapter只隐藏了一个。
将Facade置于一个非常复杂的对象之前，而用Adapter来包装几个共同实现所需功能的小对象，也是可能的。
Adapter模式是一个很常用的模式，它将一个（或多个）类的接口转换成我们需要类所具备的另一个接口。
它的实现方式是：创建一个具备所需接口的新类，然后包装原有类的方法，这样实际上就包含了被适配的对象。
3.3 Bridge模式
Bridge模式的意图是将抽象与其实现解耦，使它们都可以独立地变化。
Bridge模式是最难理解的模式，部分原因是它的功能非常强大，适用于很多场合。
而且，它还与常见的用继承来处理特殊情况的方式背道而驰。
但是，它却是一个遵循设计模式社区两大原则的极好例子：“找出变化并封装之”和“优先使用对象聚集，而不是类继承”。
图3-3 Bridge模式的一般结构图
Bridge模式的实现过程分两步。
第一步，将实现封装在一个抽象类中。
第二步，在要实现的抽象的基类中包含一个实现的句柄。
在Java中，可以在实现中使用借口来代替抽象类。
3.4 Strategy 模式
Strategy 模式的意图是定义一系列的算法，把它们一个个封装起来，并且使它们可以相互替换。
这个模式使算法可独立于使用它的客户而变化。
对所需算法的选择取决于发出请求的客户或者要处理的数据。
如果只有一些不会变化的算法，就不需要Strategy模式。
图3-4 Strategy模式的通用结构图
Strategy模式是一种定义一系列算法的方法。
概念上看，所有这些算法完成都是相同的工作，只是实现不同。
Strategy模式的实现方式是让使用算法的类包含一个抽象类，该抽象类有一个抽象方法指定如何调用算法。
每个派生类按需要实现算法。
3.5 Factory Method模式
Factory Method模式是一个旨在帮助创建责任分配的模式。
Factory Method模式的意图是：定义一个用于创建对象的接口，让子类决定实例化哪一个类。
Factory Method使一个类的实例化延迟到其子类。
Factory Method模式已经在所有主要的面向对象语言中实现了：
（1）在Java中，集合的iterator方法是工厂方法。
这一方法返回被请求集合的迭代器的正确类型。
（2）在C#中，集合实现了IEnumerable接口。
这一接口定义了GetEnumerator方法，这是一个获取集合迭代器的工厂方法。
（3）在C++中，用到的工厂方法包括begin()和end()。
所有这些情况下，用来获取正确迭代器的方法都使用了Factory Method模式。
图3-5 Factory Method模式的通用结构图
Factory Method模式的实现方法是在抽象类中使用一个抽象方法（即C++的纯虚函数）。
需要实
例化一个被包含对象的时候抽象类的代码将引用此方法，但是不知道需要的对象是哪一个。
Factory Method模式是一个很简单的模式，在实际应用中会不断用到。
它可以用于需要将对象实例化的规则推迟到某个派生类的情况。
在这种情况下，将方法的实现放在负责该行为的对象中，最自然。
4 结语
设计模式为我们的软件开发提供了非常有价值的经验和方法。
通过在开发团队中使用设计模式的经验证明，设计模式既可以帮助开发人员个人的学习，也可以帮助团队的提高。
这是因为，经验较少的团队成员能够亲眼看到已经掌握设计模式的资深开发人员如何从中获益，他们会更加自豪、主动地学习这些强大的知识。
大多数设计模式还能使软件更容易修改和维护。
其原因在于，它们都是久经考验的解决方案。
所以，它们的结构都是经过长期发展形成的，比新构思的解决方案更善于应对变化。
而且，这些模式所用代码往往更易于理解，从而使代码更易维护。
设计模式还有一个好处是，你或者你的团队可以在不使用巨型继承层次结构的情况下，为复杂问题创建出设计方案。
同样，即使并不直接使用设计模式，不使用巨型继承层次结构也会使软件设计质量提高。
参考文献
（1）程杰．大话设计模式[M]．北京：清华大学出版社，2007．
（2）齐治昌，董威，文艳军，陈振邦．软件设计与体系结构[M]．北京：高等教育出版社，2010．（3）[美]Eric J.Braude著，李仁发，王岢，任小西等译．软件设计—从程序设计到体系结构[M]．北京：电子工业出版社，2005．。
