本文摘取自TerryLee(李会军)老师的设计模式系列文章，版权归TerryLee，仅供个人学习参考。转载请标明原作者TerryLee。
设计模式
模式是在某种情境（Context）下，针对某问题的某种解决方案。
这其中
-
情境就是应用某个模式的情况。这个应该是会不断出现的情况。
-
问题就是你想在某情境下达到的目标，也可以是某情境下的约束。
-
解决方案就是你所追求的：一个通用的设计，用来解决约束、达到目标。
设计模式是规则吗？
地上本没有路，走得人多了也就成了路。设计模式如同此理，它是经验的传承，并非体系；是被前人发现，经过总结形成了一套某一类问题的一般性解决方案，而不是被设计出来的定性规则；它不像算法那样可以照搬照用。
设计模式是架构吗？
架构和模式应该是一个属于相互涵盖的过程，但是总体来说架构更加关注的是所谓的High-Level Design,而模式关注的重点在于通过经验提取的“准则或指导方案”在设计中的应用，因此在不同层面考虑问题的时候就形成了不同问题域上的模式。模式的目标是，把共通问题中的不变部分和变化部分分离出来。不变的部分，就构成了模式，因此，模式是一个经验提取的“准则”，并且在一次一次的实践中得到验证，在不同的层次有不同的模式，小到语言实现，大到架构。在不同的层面上，模式提供不同层面的指导。
设计模式，软件的永恒之道？
这个问题没有答案，有的只是讨论，看一下一位前辈结合建筑学得出的几点心得吧：
和建筑结构一样，软件中亦有诸多的“内力”。和建筑设计一样，软件设计也应该努力疏解系统中的内力，使系统趋于稳定、有生气。一切的软件设计都应该由此出发。
任何系统都需要有变化，任何系统都会走向死亡。作为设计者，应该拥抱变化、利用变化，而不是逃避变化。
好的软件只能“产生”而不能“创造”，我们所能做的只是用一个相对好的过程，尽量使软件朝向好的方向发展。
需要设计模式吗？
答案是肯定的，但你需要确定的是模式的应用是否过度？我得承认，世界上有很多天才的程序员，他可以在一段代码中包含6 种设计模式，也可以不用模式而把设计做得很好。但我们的目标是追求有效的设计，而设计模式可以为这个目标提供某种参考模型、设计方法。
我们不需要奉GOF的设计模式为圭臬，但合理的运用设计模式，才是正确的抉择。很多人看过GOF的《Design Patterns》，对这23 种模式也背得滚瓜烂熟。但重要的不是你熟记了多少个模式的名称，关键还在于付诸实践的运用。为了有效地设计，而去熟悉某种模式所花费的代价是值得的，因为很快你会在设计中发现这种模式真的很好，很多时候它令得你的设计更加简单了。
其实在软件设计人员中，唾弃设计模式的可能很少，盲目夸大设计模式功用的反而更多。言必谈“模式”，并不能使你成为优秀的架构师。真正出色的设计师，懂得判断运用模式的时机。还有一个问题是，很多才踏入软件设计领域的人员，往往对设计模式很困惑。对于他们来说，由于没有项目的实际经验，OO 的思想也还未曾建立，设计模式未免过于高深了。其实，即使是非常有经验的程序员，也不敢夸口对各种模式都能合理应用。
经典设计模式包含23种，被归为创建型模式、结构型模式和行为型模式三类。学习设计模式从这三类模式出现的原因和解决的问题入手是个很好的方法。从大的方向了把我了23个模式的初衷再去各自学习就犹如抽丝剥茧，很快就能融会贯通了。
创建型模式（Creational Pattern）
概述
创建型模式，就是用来创建对象的模式，抽象了实例化的过程。它帮助一个系统独立于如何创建、组合和表示它的那些对象。本文对五种常用创建型模式进行了比较，通过一个游戏开发场景的例子来说该如何使用创建型模式。
为什么需要创建型模式
所有的创建型模式都有两个永恒的主旋律：第一，它们都将系统使用哪些具体类的信息封装起来；第二，它们隐藏了这些类的实例是如何被创建和组织的。外界对于这些对象只知道它们共同的接口，而不清楚其具体的实现细节。正因如此，创建型模式在创建什么（what），由谁（who）来创建，以及何时（when）创建这些方面，都为软件设计者提供了尽可能大的灵活性。
假定在一个游戏开发场景中，会用到一个现代风格房屋的对象，按照我们的一般想法，既然需要对象就创建一个：
ModernRoom room = new ModernRoom();
好了，现在现代风格房屋的对象已经有了，如果这时房屋的风格变化了，需要的是古典风格的房屋，修改一下：
ClassicalRoom room = new ClassicalRoom();
试想一下，在我们的程序中有多少处地方用到了这样的创建逻辑，而这里仅仅是房屋的风格变化了，就需要修改程序中所有的这样的语句。现在我们封装对象创建的逻辑，把对象的创建放在一个工厂方法中：
ModernFactory factory = new ModernFactory(); ModernRoom room = factory.Create();
当房屋的风格变化时，只需要修改
ClassicalFactory factory = new ClassicalFactory(); ClassicalRoom room = factory.Create();
而其它的用到room的地方仍然不变。这就是为什么需要创建型模式了。创建者模式作用可以概括为如下两点：
-
封装创建逻辑，绝不仅仅是new一个对象那么简单。
-
封装创建逻辑变化，客户代码尽量不修改，或尽量少修改。
常见的五种创建型模式
单件模式（Singleton Pattern）解决的是实体对象的个数问题，其他的都是解决new所带来的耦合关系问题。
工厂方法模式（Factory Pattern）在工厂方法中，工厂类成为了抽象类，其实际的创建工作将由其具体子类来完成。工厂方法的用意是定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类中去，强调的是“单个对象”的变化。
抽象工厂模式（Abstract Factory）抽象工厂是所有工厂模式中最为抽象和最具有一般性的一种形态。抽象工厂可以向客户提供一个接口，使得客户可以在不必指定产品的具体类型的情况下，创建多个产品族中的产品对象，强调的是“系列对象”的变化。
生成器模式（Builder Pattern）把构造对象实例的逻辑移到了类的外部，在这个类的外部定义了这个类的构造逻辑。他把一个复杂对象的构造过程从对象的表示中分离出来。其直接效果是将一个复杂的对象简化为一个比较简单的目标对象。他强调的是产品的构造过程。
原型模式（Prototype Pattern）和工厂模式一样，同样对客户隐藏了对象创建工作，但是，与通过对一个类进行实例化来构造新对象不同的是，原型模式是通过拷贝一个现有对象生成新对象的。
如何选择使用创建型模式
继续考虑上面提到的游戏开发场景，假定在这个游戏场景中我们使用到的有墙（Wall），屋子（Room），门（Door）几个部件。在这个过程中，同样是对象的创建问题，但是会根据所要解决的问题不同而使用不同的创建型模式。
如果在游戏中，一个屋子只允许有一个门存在，那么这就是一个使用Signleton模式的例子，确保只有一个Door类的实例被创建。解决的是对象创建个数的问题。
示例代码：
using System;
public sealed class SigletonDoor
{
static readonly SigletonDoor instance=new SigletonDoor();
static SigletonDoor()
{
}
public static SigletonDoor Instance
{
get
{
return instance;
}
}
}
在游戏中需要创建墙，屋子的实例时，为了避免直接对构造器的调用而实例化类，这时就是工厂方法模式了，每一个部件都有它自己的工厂类。解决的是“单个对象”的需求变化问题。
示例代码：
using System;
public abstract class Wall
{
public abstract void Display();
}
public class ModernWall:Wall
{
public override void Display()
{
Console.WriteLine("ModernWall Builded");
}
}
public abstract class WallFactory
{
public abstract Wall Create();
}
public class ModernFactory:WallFactory
{
public override Wall Create()
{
return new ModernWall();;
}
}
在游戏场景中，不可能只有一种墙或屋子，有可能有现代风格（Modern），古典风格（Classical）等多系列风格的部件。这时就是一系列对象的创建问题了，是一个抽象工厂的例子。解决的是“系列对象”的需求变化问题。
示例代码：
using System;
public abstract class Wall
{
public abstract void Display();
}
public class ModernWall:Wall
{
public override void Display()
{
Console.WriteLine("ModernWall Builded");
}
}
public class ClassicalWall:Wall
{
public override void Display()
{
Console.WriteLine("ClassicalWall Builded");
}
}
public abstract class Room
{
public abstract void Display();
}
public class ModernRoom:Room
{
public override void Display()
{
Console.WriteLine("ModernRoom Builded");
}
}
public class ClassicalRoom:Room
{
public override void Display()
{
Console.WriteLine("ClassicalRoom Builded");
}
}
public abstract class AbstractFactory
{
public abstract Wall CreateWall();
public abstract Room CreateRoom();
}
public class ModernFactory:AbstractFactory
{
public override Wall CreateWall()
{
return new ModernWall();
}
public override Room CreateRoom()
{
return new ModernRoom();
}
}
public class ClassicalFactory:AbstractFactory
{
public override Wall CreateWall()
{
return new ClassicalWall();
}
public override Room CreateRoom()
{
return new ClassicalRoom();
}
}
如果在游戏场景中，构成某一个场景的算法比较稳定，例如：这个场景就是用四堵墙，一个屋子，一扇门来构成的，但具体是用什么风格的墙、屋子和门则是不停的变化的，这就是一个生成器模式的例子。解决的是“对象部分”的需求变化问题。
示例代码：
using System;
using System.Collections;
public class Director
{
public void Construct( Builder builder )
{
builder.BuildWall();
builder.BuildRoom();
builder.BuildDoor();
}
}
public abstract class Builder
{
public abstract void BuildWall();
public abstract void BuildRoom();
public abstract void BuildDoor();
public abstract GameScene GetResult();
}
public class GameBuilder : Builder
{
private GameScene g;
public override void BuildWall()
{
g = new GameScene();
g.Add( "Wall" );
}
public override void BuildRoom()
{
g.Add( "Room" );
}
public override void BuildDoor()
{
g.Add( "Door" );
}
public override GameScene GetResult()
{
return g;
}
}
public class GameScene
{
ArrayList parts = new ArrayList();
public void Add( string part )
{
parts.Add( part );
}
public void Display()
{
Console.WriteLine( " GameScene Parts：" );
foreach( string part in parts )
Console.WriteLine( part );
}
}
如果在游戏中，需要大量的古典风格或现代风格的墙或屋子，这时可以通过拷贝一个已有的原型对象来生成新对象，就是一个原型模式的例子了。通过克隆来解决“易变对象”的创建问题。
示例代码：
using System;
public abstract class RoomPrototype
{
public abstract RoomPrototype Clone();
}
public class ModernPrototype:RoomPrototype
{
public override RoomPrototype Clone()
{
return (RoomPrototype)this.MemberwiseClone();
}
}
public class ClassicalPrototype:RoomPrototype
{
public override RoomPrototype Clone()
{
return (RoomPrototype)this.MemberwiseClone();
}
}
究竟选用哪一种模式最好取决于很多的因素。使用Abstract Factory、Prototype Pattern或Builder Pattern的设计比使用Factory Method的设计更加灵活，但是也更加复杂，尤其Abstract Factory需要庞大的工厂类来支持。通常，设计以使用Factory Method开始，并且当设计者发现需要更大的灵活性时，设计便会向其他设计模式演化，当你在多个设计模式之间进行权衡的时候，了解多个设计模式可以给你提供更多的选择余地。
总结
使用创建者模式是为了提高系统的可维护性和可扩展性，提高应对需求变化的能力！
结构型模式（Structural Pattern）
结构型模式概述
结构型模式，顾名思义讨论的是类和对象的结构，它采用继承机制来组合接口或实现（类结构型模式），或者通过组合一些对象，从而实现新的功能（对象结构型模式）。这些结构型模式，它们在某些方面具有很大的相似性，仔细推敲，侧重点却各有不同。
Adapter模式通过类的继承或者对象的组合侧重于转换已有的接口；Bridge模式通过将抽象和实现相分离，让它们可以分别独立的变化，它强调的是系统沿着多个方向的变化；Decorator模式采用对象组合而非继承的手法，实现了在运行时动态的扩展对象功能的能力，它强调的是扩展接口；Composite模式模糊了简单元素和复杂元素的概念，它强调的是一种类层次式的结构；Façade 模式将复杂系统的内部子系统与客户程序之间的依赖解耦，它侧重于简化接口，更多的是一种架构模式；Flyweight模式解决的是由于大量的细粒度对象所造成的内存开销的问题，它与Façade模式恰好相反，关注的重点是细小的对象；Proxy模式为其他对象提供一种代理以控制对这个对象的访问，它注重于增加间接层来简化复杂的问题。
结构型模式区别与比较
1．桥接模式与装饰模式
这两个模式在一定程度上都是为了减少子类的数目，避免出现复杂的继承关系。但是它们解决的方法却各有不同，装饰模式把子类中比基类中多出来的部分放到单独的类里面，以适应新功能增加的需要，当我们把描述新功能的类封装到基类的对象里面时，就得到了所需要的子类对象，这些描述新功能的类通过组合可以实现很多的功能组合，装饰模式的简略图如下：
图1 装饰模式简略图
桥接模式则把原来的基类的实现化细节抽象出来，在构造到一个实现化的结构中，然后再把原来的基类改造成一个抽象化的等级结构，这样就可以实现系统在多个维度上的独立变化，桥接模式的简略图如下：
图2 桥接模式简略图
2．外观模式和代理模式
外观模式和代理模式解决问题的侧重点不同，但是它们解决问题的手法却是一样的，即都是引入了间接层的手法，这也是我们软件系统中经常用的一种手法。外观模式虽然侧重于简化接口，但是在某些情况下，外观模式也可以兼任代理模式的责任，例如外观对象有可能是另一个位于另一个地址空间对象的远程代理，这时候我们可以叫做外观代理模式，或者代理外观模式。它们的类简略图如下：
图3 代理模式简略图
图4 外观模式简略图
3．适配器模式
适配器模式重在转换接口，它能够使原本不能在一起工作的两个类一起工作，所以经常用在类库复用，代码迁移等方面，有一种亡羊补牢的味道。类适配器和对象适配器可以根据具体实际情况来选用，但一般情况建议使用对象适配器模式，如下图所示，左边是类适配器模式，右边是对象适配器模式：
图5 适配器模式简略图
对变化的封装
如何应对变化，是软件开发的一个永恒的主题，也许我们不能够杜绝变化的发生，但至少我们可以通过一些手段让变化降到最低。“找到系统可变的因素，将之封装起来”，通常就叫做对变化的封装。关于这个问题的解释在《Java与模式》中讲的很清晰，抽象化与实现化的简单实现，也就是“开-闭”原则在类层次上的最简单实现，如下图所示：
图6
在这个继承结构中，第一层是抽象化，它封装了抽象的业务逻辑，这是系统中不变的部分；第二层是实现化，它是具体的业务逻辑的实现，封装了系统中变化的部分，这个实现允许实现化角色多态性的变化：
图7
也就是说，客户端依赖的是业务逻辑的抽象化类型的对象，而与抽象化的具体实现无关，不在乎它到底是“实现化”，“实现化2”还是“实现化3”，如下图所示：
图8
每一种继承关系都封装了一个变化因素，而一个继承关系不应当处理两个变化因素，换言之，这种简单继承关系不能处理抽象化与实现化都变化的情况，如下图所示：
图9
上图中的两个变化因素应当是独立的，可以在不影响另一者的情况下独立的变化，如下面这两个等级结构分别封装了自己的变化因素，由于每一个变化因素都是可以通过静态关系表达的，因此分别使用继承关系实现，如下图：
图10
在抽象化和实现化之间的联系怎么办呢？好的设计只有一个，不好的设计却有很多中，下面这种设计就是继续使用继承进行静态关系设计的类图：
图11
这样的设计其实存在着很多的问题，首先出现的是多重的继承关系，随着具体实现化的增多，子类的继承关系会变得异常复杂；其次如果出现新的抽象化修正或者新的具体实现角色，就只好重新修改现有系统中的静态关系，以适应新的角色，这就违背了开放-封闭原则。正确是设计应该是使用两个独立的等级结构封装两个独立的变化因素，并在它们之间使用聚合关系，以达到功能复用的目的，这就回到了我们的桥接模式上，如下图所示：
图12
从另一个角度讲，一个好的设计通常没有多于两层的继承等级结构，或者说，如果出现两个以上的变化因素，就需要找出哪一个因素是静态的，可以使用静态关系，哪一个是动态的，必须使用聚合关系。
行为型模式（Behavioral Pattern）
行为型模式是对在不同的对象之间划分责任和算法的抽象化。行为型模式不仅仅关注类和对象的结构，而且重点关注它们之间的相互作用。
通过行为型模式，可以更加清晰地划分类与对象的职责，并研究系统在运行时实例对象 之间的交互。在系统运行时，对象并不是孤立的，它们可以通过相互通信与协作完成某些复杂功能，一个对象在运行时也将影响到其他对象的运行。
通过合理的处理方法，达到使系统升级性和维护性提高的目的。
行为型模式的三个典型特点:
-
封装变化
-
对象作为参数
-
对发送者和接收者解耦
行为型模式分为类行为型模式和对象行为型模式两种：
-
类行为型模式：类的行为型模式使用继承关系在几个类之间分配行为，类行为型模式主要通过多态等方式来分配父类与子类的职责。
-
对象行为型模式：对象的行为型模式则使用对象的聚合关联关系来分配行为，对象行为型模式主要是通过对象关联等方式来分配两个或多个类的职责。根据“合成复用原则”，系统中要尽量使用关联关系来取代继承关系，因此大部分行为型设计模式都属于对象行为型设计模式。