设计模式之总纲

一：各种模式之间的关系

创建型模式包括抽象工厂模式，建造者模式，工厂方法模式，原型模式，单例模式共计5种。

创建型模式抽象了实例化过程，帮助某个系统独立于如何创建、组合以及表示该系统所包含的对象。当系统向着更加依赖于对象复合而不是类的继承演变时，创建型模式就变得更为重要。创建型模式始终围绕两个点展开，创建什么，谁来创建，怎么创建以及什么时候创建。

结构性模式包括桥街模式，装饰模式，组合模式，享元模式，外观模式以及代理模式共计7种。

结构模式所关注的问题是如何将类与对象进行组合以便获取功能更加庞大的结构。一般情况下结构性模式都是使用继承机制将接口进行组合以及实现。

行为模式包括职责链模式。命令模式，解释器模式，迭代器模式，中介者模式，备忘录模式，观察者模式，状态模式，策略模式，模板方法以及访问者模式共计11种。

行为模式所关注的重点是算法与对象之间的职责如何分配的，行为模式通常都对类或者对象相互之间的通信形式进行描述。通常，行为模式都是依赖于继承机制在类之间分派行为的。大部分行为模式的主题是对变化进行封装，当一个应用某方面的特征会有比较频繁的改变时，行为模式会有一个对象封装这个方面。

二：设计模式的小结与总结

2.1 创建型模式

2.1.1 工厂方法模式

定义一个创建对象的接口，让子类决定实例化那一个类，工厂方法使一个类的实例化延迟到子类。再次对代码进行修改

适用于：

1. 当一个类不知道它所必须创建的对象的类是；
2. 当一个希望由子类来指定创建它所创建的对象时候；
3. 当类将创建对象的职责委托给多个帮助子类中的某一个，并且希望将哪一个帮助子类是代理者这一信息局部化时。

在工厂方法模式之，我们可以发现几个实现了相同操作并返回相同结果类型的类，实际上实例化的是不同的类，而其相同的地方就是这些被实例化的类来自同一个抽象对象，当使用者在请求创建新对象时，请求的接收者决定了为哪个对象创建实例。

2.1.2    抽象工厂模式

提供一个创建一系列相关或者相互依赖的接口，而无需指定他们的具体类

适用于：

1. 一个系列要独立于它的产品创建、组合和表示时；
   
2. 一个系统要由多个产品系列中的一个来配置时；
   
3. 要强调一个系列相关的产品对象的设计以便进行联合使用时；
   
4. 当提供产品库，而只要显示它们的接口而不是实现的时候

使用抽象工厂模式时，如果客户端有大量的分支判断，使用反射技术代替if和switch会节省大量的工作量，并增加程序的灵活性。

2.1.3   单例模式

保证类仅有一个实例，并提供一个访问它的全局访问点。

适用于：

1. 当类只能有一个实例而且第三方可以从一个公共的访问点访问它时；
2. 当一个唯一的 实例可以通过子类化来扩展，而且第三方需要在不更改代码的情况下就能使用一个扩展的实例时。

使用单例模式需要特别注意在多线程的环境下，如果多个线程有可能会同时访问一个单例对象的方法和数据，那么应该谨慎的处理线程之间的管理，避免出现不一致的情况。

2.1.4   建造者模式

将一个复杂对象的构建与它的表示分离，使得同样的构建过程，可以创建不同的表示

适用于：

1. 当需要把构造对象的实例转移到类的外面去，在这个类的外部去定义其构造逻辑时；
2. 当需要按照某种步骤去构造对象时。

建造者模式的精髓就是将构造逻辑分离，而把构造方法作为一个完整的单独任务去完成，甚至也可以创建单独的层次结构来完成对象的构造工作。

2.1.5  原型模式

用原型模式指定创建对象的种类，并且通过拷贝这些原型创建新的对象

适用于

1. 当要实例化的类实在运行时刻指定时；
2. 为了避免创建一个与产品类层次平行的工厂类层次时；
3. 当一个类的实例只能有几个不同状态组合中的一种时。

2.2   结构型模式

2.2.1 桥接模式

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

适用于

1. 当不希望在抽象和它的实现部分之间有一个固定的绑定关系时；
2. 当类的抽象以及它实现部分都应可以通过生成子类的方法加以扩充时；
3. 当对一个抽象类的实现部分的修改应对客户端不产生影响时（不需要重新编译）；

2.2.2 适配器模式

将一个类的接口转换成客户希望的另外一个接口，适配器模式使得原本由于接口不兼容而不能在一起工作的哪些类可以在一起工作

适用于

1. 当想要使用一个已经存在的类，但是该类的接口不符合现有的需求时候；
2. 当需要创建一个可以被复用的类，该类能够与其他无关的类甚至无法预见的类协同工作的时候；
3. 当需要使用一些已经存在的子类，但是不可能对所有的都进行子类化以匹配它们的接口时，对象适配器可以对其父类接口进行适配

一般来说，类适配器的灵活性比较差，而对象适配器比较灵活，可以通过依赖注入的方式或者配置的方式来实现灵活性。类适配器需要继承自要去适配的旧系统的类，而这并不是一个好方法。

2.2.3 装饰者模式

动态的给一个对象添加一些额外的职责，就增加功能来说，装饰者模式比生成子类会更加灵活

适用于

1. 但需要以不影响其他对象为前提实现动态、透明地给单个对象添加职责的时候；
2. 当需要将对象的某些职责进行撤销操作的时候；
3. 当不能用生成子类的方法进行当前系统的扩充时。

2.2.4 组合模式

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

适用于

1. 开发需要表示整体与部分之间的关系时；
2. 希望用户忽略组合对象和单个对象的不同时

2.2.5  享元模式

运用共享技术有效地支持大量细粒度的对象

适用于

1. 一个应用程序使用了大量的对象；
2. 由于使用大量对象造成比较巨大的存储开销时；
3. 对象的很多状态都可以改变为外部状态时；
4. 使用外部状态后可以用较少的共享对象取代大量对象时

2.2.6 外观模式

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

适用于

1. 当需要为一个复杂的子系统提供一个简单接口的时候；
2. 当客户端与抽象类的实现部分之间存在很大依赖性的时候；
3. 当需要构建一个层次结构的系统的时候

一般情况下，我们应该对某个子系统中的类进行重构，以便于每个类都具有一个被良好定义的功能目标，这样可以使代码更加易于维护，但是这样容易导致客户端对子系统难以适从，为了方便客户更加方便的使用子系统的代码，我们应该为所开发的系统提供一个便于客户使用的外观。

2.2.7 代理模式

为其他对象提供一种代理以控制对这个对象的访问

适用于

1. 为一个对象在不同的地址空间提供局部代表的时候；
2. 创建开销非常大的对象时；
3. 需要控制原始对象的访问时；
4. 当需要在访问对象时执行一些附加操作的时（比如计算访问次数）

一个普通对象为了完成自己的工作，必须对外界提供一个public接口，但是有时候，一个健康的对象无法完成自己本身的工作，这时候我们使用代理对象，让这个代理对象负责接受客户端发来的请求，然后将请求转发给真正的对象去完成的对象

2.3   行为模式

2.3.1 职责链模式

使各个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合程度，将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理他们为之

适用于

1. 当有多个对象可以处理同一个请求，而具体哪个对象来处理这个请求在运行时自动判断；
2. 当需要在不明确接受者的情况下，向多个对象中的某一个提交请求时；
3. 当处理一个请求的对象集合应该动态被确定时

2.3.2 命令模式

将一个请求封装成对象，从而使用户可用不同的请求对客户进行参数化，对请求排队或记录请求日志，并支持可撤销操作

适用于

1. 当需要抽象出待执行的动作以便于参数化某个对象时；
2. 当需要在不同时刻执行、排列以及执行请求时；
3. 当系统需要支持取消操作时；
4. 当系统需要记录修改日志时

命令模式的关键在于引入了抽象的命令接口，并且发送者针对抽象命令接口进行编程，只有实现了抽象命令接口的具体命令才能与接收者相互关联

2.3.3 解释器模式

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

适用于

1. 当有一个语言需要被解释继而执行，并且可以将该语言中的句子表示为一个抽象的语法树时

2.3.4 迭代器模式

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

适用于

1. 需要访问一个聚集对象的内容而不想暴露它的内部表示时；
2. 当希望支持对聚集对象的多种遍历方式时；
3. 当需要为遍历不同的聚集结构提供统一的对外接口时。

将遍历聚合对象中数据的行为提取出来，并封装在一个迭代器中，通过专门的迭代器去遍历聚合对象中的内部数据，这是迭代器模式的本质，也是单一职责原则的完美体现。

2.3.5 中介者模式

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

适用于

1. 当一组对象以良好定义但是复杂的方式进行通信时，所产生的相互依赖关系结构混乱并且难以理解时；
2. 当一个对象要引用很多其他对象并且直接与这些对象进行通信导致难以复用该对象时；
3. 当开发人员要定制一个分布在多个类中的行为但是却不想生成太多子类的时候

中介者模式很容易在系统中获得使用，也很容易被误用，在使用前要先考虑自己的设计时候合理。

2.3.6 备忘录模式

在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以将该对象回复到原先的状态。

适用于

1. 当必须保存一个对象在某时刻的全部或部分状态以便于在需要时将其恢复到先前状态时；
2. 当使用接口让其他对象直接得到自己的状态会暴露对象的实现细节，继而破坏其封装性时

备忘录模式尤其适用功能比较复杂而且需要维护或者记录属性的历史的类，此外，当需要保存的属性仅仅是众多属性中很少的一部分时，也可以根据之前保持的信息还原到之前的状态。

2.3.7 观察者模式

观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象，这个主题对象在状态发生改变时，会通知所有的观察者对象，让他们自动更新自己

适用于

1. 当一个抽象模型有两个方面，而其中一个方面必须依赖另一个方面时；
2. 当对一个对象的改变需要同时改变其他对象但是却不知道具体多少个对象等待改变时；
3. 当一个对象必须通知其他对象但是却不能与其他对象造成紧密的耦合时；

 2.3.8 状态模式

当一个对象的内在状态改变时，允许改变其行为，这个对象看起来像是改变了其类

适用于

1. 当一个对象的行为取决于它的状态并且必须在运行时根据状态来改变自己的行为时；
2. 当一个操作中含有大量多分支条件语句，并且这些分支都依赖该对象的状态时

状态模式主要解决控制对象状态转换的条件表达式过于复杂的情况，也就是把状态的判断逻辑进行转移，使之迁移到表示不同状态的一系列的类中去，这样就可以把复杂逻辑判断简单化了。同样，如果状态的判断比较简单时则无需使用状态模式。

2.3.9 策略模式

策略模式定义了算法家族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化不会影响到使用算法的客户

适用于

1. 很多相关类只是在行为上存在差异；
2. 当需要使用一个算法的不同变体时；
3. 当使用算法的客户不应该知道算法的具体结构时；
4. 当一个类定义了多种行为并且这些行为在这个类的操作中以多个条件语句的形式出现时

在一般情况下，客户可以通过一个变量来保存自己所选中的策略，这样一来，执行某个策略就变得很简单，因为我们只需要将对策略的调用转发给前面的变量，然后通过多态来执行正确的策略，通过应用策略模式，我买了可以在不用的类中封装一些可以相互替换的策略，同时这些类都会实现一个公共的操作。

2.3.10 模板方法模式

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

适用于

1. 一次性实现一个算法不变的部分，而将可变的部分留给子类来实现；
2. 当子类中有公共的行为可以提取到公共的父类当中去，并且子类有自己的个性化要求时；
3. 一般系类需要扩展的地方都是固定的，即允许在这些点进行扩展

2.3.11 访问者模式

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

适用于

1. 当一个对象结构包含很多类对象，但有不同接口，且希望开发人员对这些对象实施一些依赖于具体类的操作时；
2. 当需要对一个对象结构中的对象进行很多不同的并且不相关的操作时；
3. 当该对象结构被很多应用共享时

花了点时间整理学习笔记，也是对设计模式的一个整体概述。后期有了更加深入，更细致的自己的理解后，当能继续完善对设计模式的理解。

以上内容，整理自刘径舟，张玉华编著的《设计模式其实很简单》读书笔记，欢迎转载