23种设计模式

1. 模板方法模式

• 定义一个操作中算法的骨架(稳定),而将一些步骤(变化)延迟到子类中。
• 可以使得子类不改变一个算法的结构即可重定义该算法的某些步骤。
• “不要调用我，让我来调用你”

2. 策略模式

• 定义一系列算法，把它们一个个封装起来，并且使它们可相互替换(变化)。该模式使得算法可独立于使用它的客户程序(稳定)而变化
• 对于变化部分抽出接口，让客户端依赖接口(稳定)而不是依赖细节(变化)
• 策略模式提供了用条件判断语句以外的一种选择，消除条件判断语句，就是在解耦合

3. 观察者模式

• 定义对象间的一种一对多(变化)的依赖关系，以便当一个对象(subject)的状态发生改变时，所有依赖它的对象(observer)都得到通知并自动更新。
• subject应该依赖observer的基类(稳定)

4. 装饰模式

• 动态(组合)地一个对象的功能进行增强。就增强功能而言，装饰模式比生成子类(继承)更为灵活
• 同时用了继承和组合；继承为了完善接口的规范，组合是为了增强功能。

5. 桥接模式

• 将抽象部分与实现部分分离，使它们都可以独立地变化
• 当一个类有多个非常强的变化维度，找到变化维度，将每个变化维度都抽出接口，然后这个类依赖这些接口(稳定)而不是细节(变化)
• 利用了组合关系(组合也是组合基类，而不是具体子类)

6. 工厂方法模式

• 定义一个用于创建对象的工厂接口，让子类工厂去决定实例化哪个类。
• 对象的是使用者只依赖对象的工厂接口(稳定)而不去依赖具体对象(变化)。
• 工厂方法中使得一个类的实例化延迟到子类

7. 抽象工厂模式

• 提供一个工厂接口，让该接口负责创建一系列相关或者相互依赖的对象，无需指定它们具体的类。
• 重点强调工厂创建的一系列的对象之间有相互依赖或相互作用的关系。不同系列的对象之间不能相互依赖。
• 对象的使用者只依赖这个工厂接口(稳定)而不依赖具体的对象(变化)

8. 原型模式

• 使用原型实例指定创建对象的种类，然后通过拷贝这些原型来创建新的对象
• 利用了对象的深克隆

9. 构造者模式

• 在软件系统中，有时候面临着一个复杂对象的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈地变化，但是它们组合在一起的算法却相对稳定
• 将一个对象的构建和表示向分离，使得同样的构建过程(稳定)可以创建不同的表示(变化)

10. 单例模式

• 保证一个类仅有一个实例，并提供一个该实例的全局访问点
• 为了保证性能

11. 享元模式

• 运用共享技术有效地支持大量细粒度的对象
• 为了保证性能

12. 外观模式

• 在组件构建过程中，某些接口之间直接的依赖常常会带来很多问题，甚至根本无法实现，采用添加一层间接(稳定)接口，来隔离本来相互紧密关联的接口是一种常见的解决方案。
• 为子系统中的一组接口(变化)提供一个一致(稳定)的界面。外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用(复用)

13. 代理模式

• 在面向对象系统中，有些对象由于某种原因(比如对象创建的开销很大，或者某些操作需要安全控制，或者需要进程外的访问等)直接访问会给使用者、或者系统结构带来很多麻烦
• 为其他对象提供一种代理以控制(隔离，使用接口)对这个对象的访问。
• 增加间接层，来实现不为外界所知(透明)的功能
• 代理模式并不一定要求保持接口完整的一致性，只要能够实现间接控制，有时候损失一些透明性也是可以的

14. 适配器模式

• 在软件系统中，由于应用环境的变化，常常需要将一些现存的对象放到新的环境中应用，但是新环境要求的接口时这些现存对象所不满足的
• 将一个类的接口转换成客户希望的另一个接口，使得原本由于接口不兼容而不能一起工作的那些类可以一起工作
• 分为对象适配器(松耦合)和类适配器(不推荐)

15. 中介者模式

• 在软件构造过程中，经常会出现多个对象相互关联交互的情况，对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将面临不断的变化
• 用一个中介对象来封装(封装变化)一系列的对象交互。中介者使各对象不需要显示的相互引用(编译时依赖->运行时依赖),从而使其耦合松散(管理变化),而且可以独立改变他们之间的交互。
• 中介者和对象之间双向依赖，对象之间没有依赖。

16. 状态模式

• 在软件构建过程中，某些对象的状态如果改变，其行为也会随之而发生改变，比如文档处于只读状态，其支持的行为和读写状态支持的行为就可能完全不同
• 将状态和其相关的行为封装为对象。在对象状态切换时也切换相应的对象
• 允许一个对象在其内部状态改变时改变它的行为，从而使对象看起来似乎修改了其行为。

17. 备忘录模式

• 在软件构造过程中，某些对象的状态在转换过程中，可能由于某种需要，要求程序能够回溯到对象之前处于某个点时的状态。如果使用一些公有接口来让其他对象得到对象的状态，便会暴露对象的细节实现
• 在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样以后就可以将该对象恢复到原先保存的状态。

18. 组合模式

• 当软件在某些情况下，客户代码过多地依赖于对象容器复杂的内部实现结构，对象容器内部实现结构(而非抽象接口)的变化将引起客户代码的频繁变化，带来了代码的维护性、扩展性等弊端。
• 将对象组合成树形结构以表示“部分-整体”的层次结构。使得用户对单个对象和组合对象的使用具有一致性(稳定)

19. 迭代器模式

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

20. 责任链模式

• 在软件构造过程中，一个请求可能被多个对象处理，但是每个请求在运行时只能有一个接受者，如果显示指定，将必不可少地带来请求者与接受者的紧耦合
• 使多个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递请求，直到有一个对象处理它为止。

21. 命令模式

• 在软件构造过程中，行为请求者与行为实现者通常呈现一种紧耦合，但在某些场合，比如需要对行为进行“记录，撤销、重做、事务”等处理，这种无法抵御变化的紧耦合是不合适的。
• 将请求(行为)封装成对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作

22. 访问者模式

• 在软件构建过程中，由于需求的改变，某些类层次结构中常常需要增加新的行为(方法)，如果直接在基类中做这样的更改，将会给子类带来很繁重的变更负担，甚至破坏了原有设计
•  表示一个作用于某对象结构中的各个元素的操作。使得可以在不改变(稳定)各元素的类的前提下定义(扩展)作用于这些元素的新操作(变化)