设计模式纵横谈学习笔记

设计模式纵横谈

设计模式原则

1、单一职责原则（SRP）：

一个类应有仅有一个引起它变化的原因。 2、开放封闭原则（OCP）：

类模块应该是可扩展的，但是不可修改（对扩展开放，对更改封闭）。内模块不可以修改，但可以新增功能。

3、Liskov替换原则（LSP）：

子类必须能够替换它们的基类。如果调用的是父类的话，那么换成子类也完全可以运行。 4、依赖倒置原则（DIP）：

高层模块（改变速度慢）不应该依赖于低层模块（改变速度快），二者都应该依赖于抽象。抽象不应该依赖于实现细节，实现细节应该依赖于抽象。主要是在构造对象时可以动态的创建各种具体对象，当然如果一些具体类比较稳定，就不必在弄一个抽象类做它的父类，这样有画蛇添足的感觉。 5、接口隔离原则（ISP）：

不应该强迫客户程序依赖于它们不用的方法。定制服务的例子，每一个接口应该是一种角色，不多不少，不干不该干的事，该干的事都要干 。 6、合成/聚合复用原则

少用继承，多用合成关系来实现。

模式分类

1、从目的来看：

创建型（Creational）模式：负责对象创建。

单件模式、抽象工厂模式、建造者模式、工厂模式、原型模式。 结构型（Structural）模式：处理类与对象间的组合。

适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式。 行为型（Behavioral）模式：类与对象交互中的职责分配。

模版方法模式、命令模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式、状态模式、策略模式、职责链模式、访问者模式。 2、从范围来看：

类模式处理类与子类的静态关系。 对象模式处理对象间的动态关系。

Singleton单件（创建型模式）

一、动机（Motivation）

特殊类，在系统中只存在一个实例。如何绕过常规的构造器，提供一种机制来保证一个类只有一个实例？

二、意图（Intent）

保证一个类仅有一个实例，并提供一个该实例的全局访问点。 三、单线程Singleton模式实现

Singleton模式中的实例构造器可以设置为protected以允许子类派生。 Singleton模式一般不要支持ICloneable接口（实例的克隆），因为这可能会导致多个对象实例，与Singleton模式的初衷违背。

Singleton模式一般不要支持序列化，因为这也可能导致多个对象实例。

Singleton模式只考虑到了对象创建的管理，没有考虑对象销毁的管理。就支持垃圾回收平台和对象的开销来讲，我们一般没有必要对其销毁进行特殊的管理。 不能应对多线程环境。

public class Singleton

{ private static Singleton instance; private Singleton() { }

public static Singleton Instance { get

{ if(instance == null)

instance = new Singleton(); return instance;} }}

私有的实例构造器是为了屏蔽默认产生的构造器，让类的使用者无法调用构造器。 四、多线程Singleton模式实现

public class Singleton

{ private static volatile Singleton instance; private static object lockHelper=new Object(); private Singleton() { }

public static Singleton Instance { get

{ if(instance==null) { lock (lockHelper) if(instance==null)

instance = new Singleton();} return instance;} }}

volatile修饰：编译器在编译代码的时候会对代码的顺序进行微调，用volatile修饰保证了严格意义的顺序。一个定义为volatile的变量是说这变量可能会被意想不到地改变，这样，编译器就不会去假设这个变量的值了。精确地说就是，优化器在用到这个变量时必须每次都小心地重新读取这个变量的值，而不是使用保存在寄存器里的备份。

Abstract Factory抽象工厂（创建型模式）

一、new的问题

常规的对象创建方法： Road road=new Road（）； New的问题：

实现依赖，不能应对“具体实例化类型”的变化。 解决思路：

封装变化点——哪里变化，封装哪里。

面向接口编程——依赖接口、而非依赖实现。 最简单的解决方法： Class RoadFactory{

Public static Road CreateRoad(){

Return new Road();}}

客户程序：Road road = RoadFactory.CreateRoad(); 二、如何解决

使用面向对象的技术来“封装”变化点。 三、动机

在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作；同时，由于需求的变化，往往存在更多系列对象的创建工作。 四、意图

提供一个接口，让该接口负责创建一系列“相关或者相互依赖的对象”，无需指定它们具体的类。 五、要点

如果没有应多“多系列对象构建”的需求变化，则没有必要使用Abstract Factory模式，这时候使用简单的静态工厂完全可以。

“系列对象”指的是这些对象之间有相互依赖、或作用的关系，例如游戏开发场景中的“道路”与“房屋”的依赖，“道路”与“地道”的依赖。 Abstract Factory模式主要在于应对“新系列”的需求变动。其缺点在于难以应对“新对象”的需求变动。 Abstract Factory模式经常和Factory Method模式共同组合来应对“对象创建”的需求变化。

Factory Method工厂方法模式（创建型模式）

一、从耦合关系谈起

耦合关系直接决定着软件面对变化时的行为

——模块与模块之间的紧耦合使得软件面对变化时，相关的模块都要随之更改 ——模块与模块之间的松耦合使得软件面对变化时，一些模块更容易被替换或者更改，但其他模块保持不变。 二、动机

在软件系统中，经常面临着“某个对象”的创建工作：由于需求的变化，这个对象的具体实现经常面临着剧烈的变化，但是它却拥有比较稳定的接口。

如何提供一种“封装机制”来隔离出“这个易变对象”的变化，从而保持系统中“其他依赖该对象的对象”不随着需求的改变而改变？ 三、意图

定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使得一个类的实例化延迟到子类。 四、要点 Factory Method模式主要用于隔离类对象的使用者和具体类型之间的耦合关系。面对一个经常变化的具体类型，紧耦合关系会导致软件的脆弱。 Factory Method模式通过面向对象的手法，将所要创建的具体对象工作延迟到子类，从而实现一种扩展（而非更改）的策略，比较好地解决了这种紧耦合关系。 Factory Method模式解决“单个对象”的需求变化，Abstract Factory模式解决“系列对象”的需求变化，Builder模式解决“对象部分”的需求变化。 汽车：

abstract class AbstractCar {

public void Startup(); public void Run();

public void Turn(Direction direction); public void Stop();

} 汽车工厂：

abstract class CarFactory {

public abstract AbstractCar CreateCar(); }

public class HongqiCarFactory : CarFactory {

public override AbstractCar CreateCar() {

return new HongqiCar(); } } 红旗汽车：

public class Enginee { }

public class HongqiCar:AbstractCar {

Enginee enginee1; Enginee enginee2; Enginee enginee3; Enginee enginee4;

public override void Startup() { } public override void Run() { }

public override void Turn(Direction direction) { } public override void Stop(); }

汽车测试：

class CarTestFramework {

public void BuildTestContext(CarFactory carFactory) {

AbstractCar c1 = carFactory.CreateCar(); AbstractCar c2 = carFactory.CreateCar(); }

public void DoTest(AbstractCar car) {

car.Run(); }

public TestData GetTestData(AbstractCar car) {

TestData t = new TestData(); return t; } }

客户程序：

static void Main(string[] args) {

CarTestFramework carTestFramework = new CarTestFramework(); carTestFramework.BuildTestContext(new HongqiCarFactory()); }

Builder生成器模式（创建型模式）

一、动机

在软件系统中，有时候面临着“一个复杂对象”的创建工作，期通常由各个部分的子对象用一定的算法构成：由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。 如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化，从而保持系统中的“稳定结构算法”不随着需求的改变而改变？ 二、意图

将一个复杂对象的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。 三、要点

Builder模式主要用于“分步骤构建一个复杂的对象”。在这其中“分步骤”是一个比较稳定的算法，而复杂对象的各个部分则经常变化。

变化点在哪里，封装哪里——Builder模式主要在于应对“复杂对象各个部分”的频繁需求变动。其缺点在于难以应对“分步骤构建算法”的需求变动。

Abstract Factory模式解决“系列对象”的需求变化，Builder模式解决“对象部分”的需求变化。Builder模式通常和Composite模式组合使用。

abstract class House { } public abstract class Builder

{ public abstract void BuildDoor(); public abstract void BuildWall(); public abstract void BuildWindows(); public abstract void BuildFloor(); public abstract void BuildHouseCeiling(); public abstract House GetHouse(); } public class GameManager

{ public static House CreateHouse(Builder builder) { builder.BuildDoor(); builder.BuildDoor(); builder.BuildWindows(); builder.BuildWindows(); builder.BuildFloor(); builder.BuildWall(); builder.BuildWall();

builder.BuildHouseCeiling(); return builder.GetHouse(); } } public class RomainHouse : House { } public class RomainHouseBuilder : Builder { public override void BuildDoor() { } public override void BuildWall() { } public override void BuildWindows() { } public override void BuildFloor() { } public override void BuildHouseCeiling() { } public override House GetHouse(); }

Prototype原型模式（创建型模式）

一、依赖关系的倒置

抽象不应该依赖于实现细节，实现细节应该依赖于抽象。 二、动机

在软件系统中，经常面临着“某些结构复杂的对象”的创建工作：由于需求的变化，这些对象经常面临着剧烈的变化，但是他们却拥有着比较稳定一致的接口。 如何向“客户程序”隔离出“这些易变对象”，从而使得“依赖这些易变对象的客户程序”不随着需求的改变而改变？ 三、意图

使用原型实例指定创建对象的种类，然后通过拷贝这些原型来创建新的对象。 四、要点

Prototype模式同样用于隔离类对象的使用者和具体类型（易变类）之间的耦合关系，它同样要求这些“易变类”拥有“稳定的接口”。

Prototype模式对于“如何创建易变类的实体对象”（创建型模式除了Singleton模式以外，都是用于解决创建易变类的实体对象的问题的）采用“原型克隆”的方法来做，它使得我们可以非常灵活地动态创建“拥有某些稳定接口”的新对象——所需工作仅仅是注册一个新类的对象（即原型），然后在任何需要的地方不断地Clone。

Prototype模式中的Clone方法可以利用.NET中的Object类的MemberwiseClone()方法或者序列化来实现深拷贝。 抽象工厂：

public abstract class NormalActor { public abstract NormalActor Clone() {

return (NormalActor)this.MemberwiseClone(); } }

public abstract class FlyActor { public abstract FlyActor Clone() {

return (FlyActor)this.MemberwiseClone(); } }

public abstract class WaterActor { public abstract WaterActor Clone() {

return (WaterActor)this.MemberwiseClone(); }

}

public class NormalActorB : NormalActor { } public class NormalActorB:NormalActor { } public class FlyActorA:FlyActor { } public class FlyActorB:FlyActor { }

public class WaterActorA:WaterActor { }

游戏系统：

public class GameSystem {

public void Run(NormalActor normalActor, FlyActor flyactor, WaterActor wateractor) {

NormalActor normalActor1 = normalActor.Clone(); NormalActor normalActor2 = normalActor.Clone(); NormalActor normalActor3 = normalActor.Clone(); NormalActor normalActor4 = normalActor.Clone(); NormalActor normalActor5 = normalActor.Clone(); FlyActor flyactor1 = flyactor.Clone(); FlyActor flyactor2 = flyactor.Clone(); WaterActor wateractor1 = wateractor.Clone(); WaterActor wateractor2 = wateractor.Clone(); }

}

将需要new的具体对象用参数传入，这样在GameSystem这个客户程序里面就只依赖于抽象而不依赖于具体了。具体的NormalActorA、FlyActorA等都不出现在GameSystem中。

客户程序：

static void Main(string[] args)

{

GameSystem gameSystem = new GameSystem();

gameSystem.Run(new NormalActorB(), new FlyActorA(), new WaterActorA()); }

有关创建型模式的讨论

Singleton模式解决的是实体对象个数的问题。除了Singleton之外，其他创建型模式解决的都是new所带来的耦合关系。

Factory Method，Abstract Factory，Builder都需要一个额外的工厂类来负责实例化“易变对象”，而Prototype则是通过原型（一个特殊的工厂类）来克隆“易变对象”。（其实原型就是一个特殊的工厂类，它只是把工厂和实体对象耦合在一起了）

如果遇到“易变类”，起初的设计通常从Factory Method开始，当遇到更多的复杂变化时，再考虑重构为其他三种工厂模式（Abstract Factory，Builder，Prototype）。 一般来说，如果可以使用Factory Method，那么一定可以使用Prototype。但是Prototype的使用情况一般是在类比较容易克隆的条件之上，如果是每个类实现比较简单，都可以只用实现MemberwiseClone，没有引用类型的深拷贝，那么就更适合了。Prototype如果要实现深拷贝，还需要在每个要克隆的类上加序列化标签，这点复杂度要考虑进程序中。

Adapter适配器模式（结构型模式）

一、适配：即在不改变原有实现的基础上，将原先不兼容的接口转换为兼容的接口。 二、动机

在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。

如何应对这种“迁移的变化”？如何既能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口？ 三、意图

将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。 四、要点

Adapter模式主要应用于“希望复用一些现存的类，但是接口又与复用环境要求不一致的情况”，在遗留代码复用、类库迁移等方面非常有用。

GoF23定义了两种Adapter模式的实现结构：对象适配器和类适配器。但类适配器采用“多继承”的实现方式，带来了不良的高耦合，所以一般不推荐使用。对象适配器采用“对象组合”的方式，更符合松耦合精神。

Adapter模式可以实现的非常灵活，不必拘泥于GoF23中定义的两种结构。例如，完全可以将Adapter模式中的“现存对象”作为新的接口方法参数，来达到适配的目的。

Adapter模式本身要求我们尽可能地使用“面向接口的编程”风格，这样才能在后期很方便地适配。

//对象适配器（常用）

class MyStack : IStack {

ArrayList list; public MyStack() {

list = new ArrayList(); }

public void Push(object item) {

list.Add(item); }

object Pop() {

return list.RemoveAt(list.Count - 1); } }

//这种实际上是一种委派的调用，本来是发送请求给MyStack，但是MyStack实际上是委

派给list去处理。MyStack在这里其实就是Adapter（适配对象），list即是Adaptee（被适配的对象），而IStack就是客户期望的接口。 //类适配器（少用）

Bridge桥接模式（结构型模式）

一、问题的出现

假如我们需要开发一个同时支持PC和手机的坦克游戏，游戏在PC和手机上功能都一样，都有同样的类型，面临同样的功能需求变化，比如坦克可能有很多种不同的型号：T50，T75，T90??

对于其中的坦克设计，我们可能很容易设计出来一个Tank的抽象基类，然后各种不同型号的Tank继承自该类;

另外的变化原因

但是PC和手机上的图形绘制、声效、操作等实现完全不同??因此对于各种型号的坦克，都要提供各种不同平台上的坦克实现：

二、动机

思考上述问题的症结：事实上由于Tank类型的固有逻辑，使得Tank类型具有了两个变化的维度——一个变化的维度为“平台的变化”，一个变化的维度为“型号的变化”。

如何应对这种“多维度的变化”？如何利用面向对象技术来使得Tank类型可以轻松地沿着“平台”和“型号”两个方向变化，而不引入额外的复杂度？ 三、意图

将抽象部分与实现部分分离，使它们都可以独立地变化。

桥模式不能只是认为是抽象和实现的分离，它其实并不仅限于此。如下面的例子，两个都是抽象的部分。更确切的理解，应该是将一个事物中多个维度的变化分离。 四、要点

Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象（Tank的型号）和实现（不同的平台）可以沿着格子的维度来变化。

所谓抽象和实现沿着各自维度的变化，即“子类化”它们（比如不同的Tank型号子类，和不同的平台子类），得到各个子类之后，便可以任意组合它们，从而获得不同平台上的不同型号。

Bridge模式有时候类似于多继承方案，但是多继承方案往往违背单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。

public abstract class Tank

{ protected TankPlatformImplementation tankImpl; public Tank(TankPlatformImplementation tankImpl)

{ this.tankImpl = tankImpl; } public TankPlatformImplementation TankImpl { get { return this.tankImpl; } set { this.tankImpl = tankImpl; } }

public abstract void Shot(); public abstract void Run(); public abstract void Stop(); }

public class T75 : Tank

{ public override void Shot() { tankImpl.DoShot(); } public override void Run(); public override void Stop(); }

public class T50 : Tank

{ public override void Shot() {

tankImpl.DoShot(); }

public override void Run(); public override void Stop(); }

public abstract class TankPlatformImplementation { public abstract void MoveTankTo(Point to); public abstract void DrawTank(); public abstract void DoShot(); }

public class PCTankImplementation:TankPlatformImplementation { public override void MoveTankTo(Point to); public override void DrawTank(); public override void DoShot(); }

public class MobileTankImplementation :TankPlatformImplementation { public override void MoveTankTo(Point to); public override void DrawTank(); public override void DoShot(); }

static void Main(string[] args)

{ TankPlatformImplementation tankImpl = new MobileTankImplementation(); T50 tank = new T50(); tank.TankImpl = tankImpl; }

Composite组合模式（结构型模式）

一、对象容易问题

在面向对象系统中，我们常会遇到一类具有“容器”特征的对象——即它们在充当对象的同时，又是其他对象的容器。

如果我们要对这样的容器对象进行处理：

上面是客户代码，客户代码里面必须要知道对象的结构，有可能还要使用递归的方法来处理这个对象，这样写耦合性就比较高。客户代码如果能只和IBox发生依赖就很好了，但是现在它还和ContainerBox和SingleBox发生了依赖，这样内部实现的细节就暴露给了外界，并且和外界产生了依赖关系。 二、动机

上述描述的问题根源在于：客户代码过多地依赖于对象容器复杂的内部实现结构，对象容器内部实现结构（而非抽象接口）的变化将引起客户代码的频繁变化，带来了代码的维护性、扩展性等弊端。

如何将“客户代码与复杂的对象容器结构”解耦？让对象容器自己来实现自身的复杂结构，从而使得客户代码就像处理简单对象一样来处理复杂的对象容器？ 三、意图

将对象组合成树形结构以表示“部分-整体”的层次结构。Composite使得用户对单个对象和组合对象的使用具有一致性。 四、要点

Composite模式采用树形结构来实现普遍存在的对象容器，从而将“一对多”的关系转化为“一对一”的关系，使得客户代码可以一致地处理对象和对象容器，无需关心处理的是单个的对象，还是组合的对象容器。

将“客户代码与复杂的对象容器结构”解耦是Composite模式的核心思想，解耦之后，客户代码将与纯粹的抽象接口——而非对象容器的复杂内部实现结构——发生依赖关系，从而更能“应对变化”。 Composite模式中，是将“Add和Remove等和对象容器相关的方法”定义在“表示抽象对象的Component类”中，还是将其定义在“表示对象容器的Composite类”中，是一个关乎“透明性”和“安全性”的两难问题，需要仔细权衡。这里有可能违背面向对象的“单一职责原则”，但是对于这种特殊结构，这又是必须付出的代价。ASP.Net控件的实现在这方面为我们提供了一个很好的示范。

Composite模式在具体实现中，可以让父对象中的子对象反向追朔；如果父对象有频繁的遍历需求，可使用缓存技巧来改善效率。

public interface IBox {

void Process(); void Add(IBox box); void Remove(IBox box); }

public class SingleBox : IBox { public void process() { } }

public class ContainerBox : IBox { ArrayList list = null; public void Add(IBox box); public void Remove(IBox box); public void Process() {

if (list != null)

foreach (IBox box in list) box.Process(); } }

class Program {

static void Main(string[] args) {

IBox box = Factory.GetBox(); //客户代码与抽象接口进行耦合 box.Process(); } }

Decorator装饰模式（结构型模式）

一、子类复子类，子类何其多

假如我们需要为游戏中开发一种坦克，除了各种不同的型号的坦克外，我们还希望在不同场合中为其增加以下一种或多种功能：比如红外线夜视功能，比如水陆两栖功能，比如卫星定位功能等等。

如果再添加一种功能D，那么需要增加的T50子类的数量可想而知，而这只是T50这个类型，如果还有其他T70等类型，那么需要新添加的子类将不可计数。 二、动机

上述描述的问题根源在于我们“过度地使用了继承来扩展对象的功能”，由于继承为类型引入的静态特质（所谓静态特质，就是说如果想要某种功能，我们必须在编译的时候就要定义这个类，这也是强类型语言的特点。静态，就是指在编译的时候要确定的东西；动态，是指运行时确定的东西），使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀（多继承）。

如何使“对象功能的扩展”能够根据需要来动态（即运行时）地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使得任何“功能扩展变化”所导致的影响降为最低？ 三、意图

动态地给一个对象增加一些额外的职责。就增加功能而言，Decorator模式比生成子类更为灵活。 四、要点

通过采用组合、而非继承的手法，Decorator模式实现了在运行时（就是在客户代码Main函数里写的代码）动态地扩展对象功能的能力，而且可以根据需要扩展多个功能。避免了单独使用继承带来的“灵活性差”和“多子类衍生问题”。

Component类在Decorator模式中充当抽象接口的角色，不应该去实现具体的行为。而且Decorator类对于Component类应该透明——换言之Component类无需知道Decorator类，Decorator类是从外部来扩展Component类的功能。

Decorator类在接口上表现为Is-A：Component的继承关系，即Decorator类继承了Component类所具有的接口。但在实现上有表现为Has-A：Component的组合关系，即Decorator类又使用了另外一个Component类。我们可以使用一个或者多个Decorator对象来“装饰”一个Component对象，且装饰后的对象仍然是一个Component对象。 Decorator模式并非解决“多子类衍生的多继承”问题，Decorator模式，应用的要点在于解决“主体类在多个方向上的扩展功能”——是为“装饰”的含义。

public class Tank

{ public abstract void Shot();

public abstract void Run(); }

public abstract class Decorator : Tank { private Tank tank;

public Decorator(Tank tank) { this.tank = tank; } public override void Shot() { tank.Shot(); } public override void Run() { tank.Run(); } }

public class DecoratorA:Decorator { public override void Shot() { base.Shot(); } public override void Run() { base.Run(); } }

public class T50 : Tank

{ public override void Shot(); public override void Run(); }

public interface IA { void ShotA(); void RunA(); }

public class T50 : Tank, IA { private void IA.ShotA(); private void IA.RunA(); public override void Shot() { this.Shot(); } public override void Run() { this.Run(); } }

class Program {

static void Main(string[] args) {

Tank tank = new T50();

DecoratorA da = new DecoratorA(); } }

Facade外观模式（结构型模式）

一、系统的复杂度

假设我们需要开发一个坦克模拟系统用于模拟坦克车在各种作战环境中的行为，其中坦克系统由引擎、控制器、车轮、车身等各子系统构成。

如何使用这样的系统

二、动机

上述A方案的问题在于组件的客户（即外部接口，或客户程序）和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战。

如何简化外部客户程序和系统间的交互接口？如何将外部客户程序的演化和内部子系统的变化之间的依赖相互解耦？ 三、意图

为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。 四、要点

从客户程序的角度来看，Facade模式不仅简化了整个组件系统的接口，同时对于组件内部与外部客户程序来说，从某种程度上也达到了一种“解耦”的效果——内部子系统的任何变化不会影响到Facade接口的变化。

Facade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Facade很多时候更是一种架构设计模式。

注意区分Facade模式、Adapter模式、Bridge模式与Decorator模式： Facade模式注重简化接口 Adapter模式注重转换接口

Bridge模式注重分离接口（抽象）与其实现

Decorator模式注重稳定接口的前提下为对象扩展功能

internal class Wheel {

public void WAction1(); public void WAction2(); }

internal class Engine {

public void EAction1(); public void EAction2(); }

internal class Bodywork {

public void BAction1(); public void BAction2(); }

internal class Controller {

public void CAction1(); public void CAction2(); }

public class TankFaacade {

Wheel[] wheels = new Wheel[4]; Engine[] engine = new Engine[4]; Bodywork bodywork = new Bodywork(); Controller controller = new Controller(); public void Start(); public void Stop(); }

Flyweight享元模式（结构型模式）

一、面向对象的代价

面向对象很好地解决了系统抽象性的问题，同时在大多数情况下，也不会损及系统的性能。但是，在某些特殊的应用中，由于对象的数量太大，采用面向对象会给系统带来难以承受的内存开销。比如图形应用中的图元等对象、字处理应用中的字符对象等。

二、动机

采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行时代价——主要指内存需求方面的代价。 如何在避免大量细粒度对象问题的同时，让外部客户程序仍然能够透明地使用面向对象的方式来进行操作？ 三、意图

运用共享技术有效地支持大量细粒度的对象。 四、要点

面向对象很好地解决了抽象性的问题，但是作为一个运行在机器中的程序实体，我们需要考虑对象的代价问题。Flyweight设计模式主要解决面向对象的代价问题，一般不触及面向对象的抽象性问题。

Flyweight采用对象共享的做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力。在具体实现方面，要注意对象状态的处理。

对象的数量太大从而导致对象内存开销加大——什么样的数量才算大？这需要我们仔细的根据具体应用情况进行评估，而不能凭空臆断。

Proxy代理模式（结构型模式）

一、直接与间接

人们对于复杂的软件系统常常有一种处理手法，即增加一层间接层，从而对系统获得一种更为灵活、满足特定需求的解决方案。

假设A要访问B三次。如果A和B是分布式中的两个机器，那么A需要跨机器调用B三次就不是很好。如果在A和B之间加一个代理对象C，并且A和C处于同一个地址空间，即同一个机器。那么A和C之间通讯是非常高效的，现在A和C之间调用三次，到某个触发点的时候，和B只需要一次的通讯，这样性能就会好很多。这样做还有一个好处，即A不需要再知道分布式通讯的内容了。

现实生活中，其实操作系统就是软件和硬件之间的代理。 二、动机

在面向对象系统中，有些对象由于某种原因（比如对象创建的开销很大，或者某些操作需要安全控制，或者需要进程外的访问等），直接访问会给使用者、或者系统结构带来很多麻烦。 如何在不失去透明操作对象的同时来管理/控制这些对象特有的复杂性？增加一层间接层是软件开发中常见的解决方式。 三、意图

为其他对象提供一种代理以控制对这个对象的访问。 四、要点

“增加一层间接层”是软件系统中对许多复杂问题的一种常见解决方法。在面向对象系统中，直接使用某些对象会来带很多问题，作为间接层的Proxy对象便是解决这一问题的常用手段。 具体Proxy设计模式的实现方法、实现粒度都相差很大，有些可能对单个对象做细粒度的控制，如copy-on-write技术，有些可能对组件模块提供抽象代理层，在架构层次对对象做Proxy。 Proxy并不一定要求保持接口的一致性，只要能够实现间接控制，有时候损及一些透明性是可以接受的。

Template Method 模版方法（行为型模式）

一、动机

在软件构建过程中，对于某一项任务，它常常有稳定的整体操作结构，但各个子步骤却有很多改变的需求，或者由于固有的原因（比如框架与应用之间的关系）而无法和任务的整体结构同时实现。

如何在确定稳定操作结构的前提下，来灵活应对各个子步骤的变化或者晚期实现需求？ 二、意图

定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。 三、要点

Template Method模式是一种非常基础性的设计模式，在面向对象系统中有着大量的应用。它用最简洁的机制（虚函数的多态性）为很多应用程序框架提供了灵活的扩展，是代码复用方面的基本实现结构。

除了可以灵活应对子步骤的变化外，“Don't call me, let me call you（不要调用我，让我来调用你）”的反向控制结构是Template Method的典型应用。

在具体实现方面，被Template Method调用的虚方法可以具有实现，也可以没有任何实现（抽象方法、纯虚方法），但一般推荐将它们设置为protected方法。

Command命令模式（行为型模式）

一、耦合与变化

耦合是软件不能抵御变化灾难的根本性原因。不仅实体对象与实体对象之间存在耦合关系，实体对象与行为操作之间也存在耦合关系。

创建型设计模式解决的创建者和被创建对象的耦合问题； 结构型设计模式解决的是实体对象和实体对象的耦合问题； 行为型设计模式解决的是实体对象和行为操作之间的耦合问题。 二、动机

在软件构建过程中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合——比如需要对行为进行“记录、撤销/重做（undo/redo）、事务”等处理，这种无法抵御变化的紧耦合是不合适的。

在这种情况下，如何将“行为请求者”与“行为实现者”解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。 三、意图

将一个请求封装为一个对象，从而使你可用不同的请求对客户（客户程序，也是行为的请求者）进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。 四、要点

Command模式的根本目的在于将“行为请求者”与“行为实现者”解耦，在面向对象语言中，常见的实现手段是“将行为抽象为对象”。

实现Command接口的具体命令对象ConcreteCommand有时候根据需要可能会保存一些额外的状态信息。

通过使用Composite模式，可以将多个“命令”封装为一个“复合命令”MacroCommand。

Command模式与C#中的Delegate（Delegate是把函数指针抽象成了为一种可被调用的行为对象）有些类似。但两者定义行为接口的规范有所区别：Command以面向对象中的“接口-实现”来定义行为接口规范，更严格，更符合抽象原则；Delegate以函数签名来定义行为接口规范，更灵活，但抽象能力比较弱。

Interpreter解释器模式（行为型模式）

一、动机（Motivation）

在软件构建过程中，如果某一特定领域的问题比较复杂，类似的模式不断重复出现，如果使用普通的编程方式来实现将面临非常频繁的变化。 在这种情况下，将特定领域的问题表达为某种语法规则下的句子，然后构建一个解释器来解释这样的句子，从而达到解决问题的目的。 二、意图（Intent）

给定一个语言，定义它的文法的一种表示，并定义一种解释器，这个解释器使用该表示来解释语言中的句子。 三、要点

Interpreter模式的应用场合是Interpreter模式应用中的难点，只有满足“业务规则频繁变化，且类似的模式不断重复出现，并且容易抽象为语法规则的问题”才适合使用Interpreter模式。 使用Interpreter模式来表示文法规则，从而可以使用面向对象技巧方便地“扩展”文法。

Interpreter模式比较适合简单的文法表示，对于复杂的文法表示，Interpreter模式会产生比较大的类层次结构，需要求助于语法分析生成器这样的标准工具。

Mediator中介者模式（行为型模式）

一、依赖关系的转化

二、动机（Motivation） 在软件构建过程中，经常会出现多个对象互相关联交互的情况，对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将面临不断地变化。

在这种情况下，我们可使用一个“中介对象”来管理对象间的关联关系，避免相互交互的对象之间的紧耦合引用关系，从而更好地抵御变化。 三、意图（Intent）

用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式的相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。 四、要点

将多个对象间复杂的关联关系解耦，Mediator模式将多个对象间的控制逻辑进行集中管理，变“多个对象互相关联”为“多个对象和一个中介者关联”，简化了系统的维护，抵御了可能的变化。

随着控制逻辑的复杂化，Mediator具体对象的实现可能相当复杂。这时候可以对Mediator对象进行分解处理。

Facade模式是解耦系统外到系统内（单向）的对相关联关系 Mediator模式是解耦系统内各个对象之间（双向）的关联关系

Iterator迭代器模式（行为型模式）

一、集合内部结构与外部访问

二、动机（Motivation）

在软件构建过程中，集合对象内部结构常常变化各异。但对于这些集合对象，我们希望在不暴露其内部结构的同时，可以让外部客户代码透明地访问其中包含的元素；同时这种“透明遍历”也为“同一种算法在多种集合对象上进行操作”提供了可能。

使用面向对象技术将这种遍历机制抽象为“迭代器对象”为“应对变化中的集合对象”提供了一种优雅的方式。 三、意图（Intent）

提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露该对象的内部表示。 四、要点

迭代抽象：访问一个聚合对象的内容而无需暴露它的内部表示。 迭代多态：为遍历不同的集合结构提供一个统一的接口，从而支持同样的算法在不同的集合结构上进行操作。

例如假设我们有一个求和算法

它可以操作在多个支持迭代器的集合上，如果把这个算法写成ArrayList的话，就会非常受限制。同时我们更可以用C#的Foreach语句来写。

我们的算法应该是独立的，写的时候应该尽量操作接口，这样我们写好一个算法，就能应对N种集合的变化，使得同样的算法能在不同的集合上操作。

迭代器的健壮性考虑：遍历的同时更改迭代器所在的集合结构，会导致问题。

也就是说，我们在迭代的时候，应该只是读取操作，不能更改容器的接口，例如遍历的时候删除一个元素，这样是不可以的。容器的结构师绝对不能碰的，一旦结构更改，遍历就会出问题。

下面这种情况对i进行更改，是不会影响原来的数组内容的，因为i是int类型，它只是一份拷贝。

我们一定要给用户提供尽量纯只读的迭代。保证每个元素被且只被遍历一次。

Observer观察者模式（行为型）

一、发布-订阅模型

当我们账户的金额有任何的操作，如果我们订阅了服务，例如手机、Email等，那么我们都会得到通知。

二、动机（Motivation） 在软件构建过程中，我们需要为某些对象建立一种“通知依赖关系”——一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。

使用面向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系。从而实现软件体系结构的松耦合。 三、意图（Intent）

定义对象间的一种一对多的依赖关系，以便当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并自动更新 四、要点

使用面向对象的抽象，Observer模式使得我们可以独立地改变目标与观察者（面向对象中的改变不是指改代码，而是指扩展、子类化、实现接口），从而使二者之间的依赖关系达致松耦合。

目标发送通知时，无需指定观察者，通知（可以携带通知信息作为参数）会自动传播。观察者自己决定是否需要订阅通知，目标对象对此一无所知。

在C#的event中，委托充当了抽象的Observer接口，而提供事件的对象充当了目标对象。委托是比抽象Observer接口更为松耦合的设计。

Chain Of Responsibility职责链模式（行为型模式）

一、请求的发送者与接受者

某些对象请求的接受者可能多种多样，变化无常……

二、动机（Motivation） 在软件构建过程中，一个请求可能被多个对象处理，但是每个请求在运行时只能有一个接受者，如果显示指定，将必不可少地带来请求发送者与接受者的紧耦合。

如何使请求的发送者不需要指定具体的接受者？让请求的接受者自己在运行时决定来处理请求，从而使两者解耦。 三、意图（Intent）

使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递请求，直到有一个对象处理它为止。 四、要点

Chain of Responsibility模式的应用场合在于“一个请求可能有多个接受者，但是最后真正的接受者只有一个”，只有这时候请求发送者与接受者的耦合才有可能出现“变化脆弱”的症状，职责链的目的就是将二者解耦，从而更好地应对变化。

应用了Chain of Responsibility模式后，对象的职责分派将更具灵活性。我们可以在运行时动态添加/修改请求的处理职责。

当我们要新增一个DHandler处理请求，就不需再改原来的代码了，遵从了开放封闭原则。这样我们的程序就更赋予变化，更有变化的抵抗力。Handler类本身继承自BaseHandler类型，又包含了一个BaseHandler类型的对象，这点类似Decorator模式。

如果请求传递到职责链的末尾仍得不到处理，应该有一个合理的缺省机制。这也是每一个接受对象的责任，而不是发出请求的对象的责任。

这种模式在处理UI的消息时很常用，但实际上Windows消息循环还是硬编码的结构。因为效率上的考虑，Windows消息循环是哪个对象有一个请求，则直接到达处理函数的地址。如果链条上的对象多了，而真正处理的函数在链条后部分，效率会很低下。因此我们在使用这种模式的时候更适合业务流程，即对性能要求不是特别高的情况更加常用。

Memento备忘录模式（行为型模式）

一、对象状态的回溯

对象状态的变化无端，如何回溯/恢复对象在某个点的状态

如果我们想恢复对象的状态，那么我们可能首先想到的是把对象保存下来，但是这样会破坏对象的封装性。因为对象有状态有操作，如果我们为了保存对象而留着原来的对象，做一个深拷贝，那么其他对象也能通过这个对象的接口访问这个对象状态，这并不是我们所希望的。而我们需要它的职责只是保存和恢复对象状态，而不应在上面支持对对象状态访问的接口，这就产生了Memento模式。 二、动机（Motivation）

在软件构建过程中，某些对象的状态在转换的过程中，可能由于某种需要，要求程序能够回溯到对象之前处于某个点时的状态。如果使用一些公有接口来让其他对象得到对象的状态，便会暴露对象的细节实现。

如何实现对象状态的良好保存与恢复？但同时又不会因此而破坏对象本身的封装性。 三、意图（Intent）

在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态（如果没有这个关键点，其实深拷贝就可以解决问题）。这样以后就可以将该对象恢复到原先保存的状态。 四、要点

备忘录（Memento）存储原发器（Originator）对象的内部状态，在需要时恢复原发器状态。Memento模式适用于“由原发器管理，却又必须存储在原发器之外的信息”。 在实现Memento模式中，要防止原发器以外的对象访问备忘录对象。备忘录对象有两个接口，一个为原发器使用的宽接口；一个为其他对象使用的窄接口。

在实现Memento模式时，要考虑拷贝对象状态的效率问题，如果对象开销比较大，可以采用某种增量式改变（即只记住改变的状态）来改进Memento模式。

我们也可以用序列化的方式实现备忘录。序列化之后，我们可以把它临时性保存到数据库、文件、进程内、进程外等地方。ASP.Net的Session其实就有这种影子。

类需要加上可序列化标记。MemoryStream是一个内存流，可以对对象进行序列化和反序列化，内存流是保存到当前进程里面。操作的时候，对对象做序列化；保存的时候，对对象做反序列化。内存流的好处是操作方便，避免了我们写很多字段来保存。 Memento模式与Command模式的异同

虽然两者都支持Undo操作，但是Command是对行为的封装，Memento是对对象状态的保留，

这是目的上的不同。它们支持的也是Undo操作的不同层面，Command是对行为序列的操作，Memento是对行为状态的操作。

State状态模式（行为型模式）

一、对象状态影响对象行为

对象拥有不同的状态，往往会行使不同的行为……

二、动机（Motivation）

在软件构建过程中，某些对象的状态如果改变，其行为也会随之而发生变化，比如文档处于只读状态，其支持的行为和读写状态支持的行为就可能完全不同。

如何在运行时根据对象的状态来透明地更改对象的行为？而不会为对象操作和状态转化之间引入紧耦合？ 三、意图（Intent）

允许一个对象在其内部状态改变时改变它的行为。从而使对象看起来似乎修改了其行为。 四、要点

State模式将所有与一个特定状态相关的行为都放入一个State的子类对象中，在对象状态切换时，切换相应的对象；但同时维持State的接口，这样实现了具体操作与状态转换之间的解耦。 为不同的状态引入不同的对象使得状态转换变得更加明确，而且可以保证不会出现状态不一致的情况，因为转换是原子性的——即要么彻底转换过来，要么不转换。 如果State对象没有实例变量，那么各个上下文可以共享同一个State对象，从而节省对象开销。

Strategy策略模式（行为型）

一、算法与对象的耦合

对象可能经常需要使用多种不同的算法，但是如果变化频繁，会将类型变得脆弱……

二、动机（Motivation）

在软件构建过程中，某些对象使用的算法可能多种多样，经常改变，如果将这些算法都编码到对象中，将会使对象变得异常复杂；而且有时候支持不使用的算法也是一个性能负担。 如何在运行时根据需要透明地更改对象的算法？将算法与对象本身解耦，从而避免上述问题？

三、意图（Intent）

定义一系列算法，把它们一个个封装起来，并且使它们可互相替换。该模式使得算法可独立于使用它的客户而变化。 四、要点

Strategy及其子类为组件提供了一系列可重用的算法，从而可以使得类型在运行时方便地根据需要在各个算法之间进行切换，所谓封装算法，支持算法的变化。

Strategy模式提供了用条件判断语句以外的另一种选择，消除条件判断语句，就是在解耦合。含有许多条件判断语句的代码通常都需要Strategy模式。

与State类似，如果Strategy对象没有实例变量，那么各个上下文可以共享一个Strategy对象，从而节省对象开销。

Strategy模式适用的是算法结构中整个算法的改变，而不是算法中某个部分的改变。

Template Method方法：执行算法的步骤协议是本身放在抽象类里面的，允许一个通用的算法操作多个可能实现

Strategy模式：执行算法的协议是在具体类，每个具体实现有不同通用算法来做。

Visitor访问者模式（行为型模式）

一、类层次结构的变化

类层次结构中可能经常由于引入新的操作，从而将类型变得脆弱……

二、动机

在软件构建过程中，由于需求的改变，某些类层次结构中常常需要增加新的行为（方法），如果直接在基类中做这样的更改，将会给子类带来很繁重的变更负担，甚至破坏原有设计。 如何在不更改类层次结构的前提下，在运行时根据需要透明地为类层次结构上的各个类动态添加新的操作，从而避免上述问题？ 三、意图

表示一个作用于某对象结构中的各个元素的操作。它可以在不改变各元素的类的前提下定义作用于这些元素的新的操作。 四、要点

Visitor模式通过所谓双重分发（double dispatch）来实现在不更改Element类层次结构的前提下，在运行时透明地为类层次结构上的各个类动态添加新的操作。

所谓双重分发即Visitor模式中间包括了两个多态分发（注意其中的多态机制）：第一个为accept方法的多态辨析；第二个为visit方法的多态辨析。

Visitor模式的最大缺点在于扩展类层次结构（增添新的Element子类），会导致Visitor类的改变。因此Visitor模式适用于“Element类层次结构稳定，而其中的操作却经常面临频繁改动”。 设计模式其实是一种堵漏洞的方式，但是没有一种设计模式能够堵完所有的漏洞，即使是组合各种设计模式也是一样。每个设计模式都有漏洞，都有它们解决不了的情况或者变化。每一种设计模式都假定了某种变化，也假定了某种不变化。Visitor模式假定的就是操作变化，而Element类层次结构稳定。

总结

创建型模式

Singleton模式解决的是实体对象个数的问题。除了Singleton之外，其他创建型模式解决的都是new所带来的耦合关系。 Factory Method，Abstract Factory，Builder都需要一个额外的工厂类来负责实例化“易变对象”，而Prototype则是通过原型（一个特殊的工厂类）来克隆“易变对象”。

如果遇到“易变类”，起初的设计通常从Factory Method开始，当遇到更多的复杂变化时，再考虑重构为其他三种工厂模式（Abstract Factory，Builder，Prototype）。

结构型模式

Adapter模式注重转换接口，将不吻合的接口适配对接（适合于旧系统） Bridge模式注重分离接口与其实现，支持多维度变化

Composite模式注重统一接口，将“一对多”的关系转化为“一对一”的关系 Decorator模式注重稳定接口，在此前提下为对象扩展功能

Facade模式注重简化接口，简化组件系统与外部客户程序的依赖关系 Flyweight模式注重保留接口，在内部使用共享技术对对象存储进行优化 Proxy模式注重假借接口，增加间接层来实现灵活控制

行为型模式

Template Method模式封装算法结构，支持算法子步骤变化 Strategy模式注重封装算法，支持算法的变化

State模式注重封装与状态相关的行为，支持状态的变化 Memento模式注重封装对象状态变化，支持状态保存/恢复 Mediator模式注重封装对象间的交互，支持对象交互的变化

Chain Of Responsibility模式注重封装对象责任，支持责任的变化 Command模式注重将请求封装为对象，支持请求的变化 Iterator模式注重封装集合对象内部结构，支持集合的变化

Interpreter模式注重封装特定领域变化，支持领域问题的频繁变化 Observer模式注重封装对象通知，支持通信对象的变化

Visitor模式注重封装对象操作变化，支持在运行时为类层次结构动态添加新的操作 模式之间的关系图

本文来源：https://www.bwwdw.com/article/9bl.html