设计模式的类型
创建型模式
这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用新的运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。
工厂模式（Factory Pattern）
抽象工厂模式（Abstract Factory Pattern）
单例模式（Singleton Pattern）
建造者模式（Builder Pattern）
原型模式（Prototype Pattern）
结构型模式
这些设计模式关注类和对象的组合。继承的概念被用来组合接口和定义组合对象获得新功能的方式。
适配器模式（Adapter Pattern）
桥接模式（Bridge Pattern）
过滤器模式（Filter、Criteria Pattern）
组合模式（Composite Pattern）
装饰器模式（Decorator Pattern）
外观模式（Facade Pattern）
享元模式（Flyweight Pattern）
代理模式（Proxy Pattern）
行为型模式
这些设计模式特别关注对象之间的通信。
责任链模式（Chain of Responsibility Pattern）
命令模式（Command Pattern）
解释器模式（Interpreter Pattern）
迭代器模式（Iterator Pattern）
中介者模式（Mediator Pattern）
备忘录模式（Memento Pattern）
观察者模式（Observer Pattern）
状态模式（State Pattern）
空对象模式（Null Object Pattern）
策略模式（Strategy Pattern）
模板模式（Template Pattern）
访问者模式（Visitor Pattern）
设计模式具体介绍
创建型模式
-
工厂模式
- 意图：定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。
- 优点：
- 一个调用者想创建一个对象，只要知道其名称就可以了
- 扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。
- 屏蔽产品的具体实现，调用者只关心产品的接口。
-
抽象工厂模式
- 意图：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。（多个工厂模式结合，不同工厂表示不同产品族）
- 优点：当一个产品族中的多个对象被设计成一起工作时，它能保证客户端始终只使用同一个产品族中的对象。
-
单例模式
- 意图：保证一个类仅有一个实例，并提供一个访问它的全局访问点。
- 优点：
- 在内存里只有一个实例，减少了内存的开销，尤其是频繁的创建和销毁实例。
- 保持数据的全局状态，可用于设计内存级缓存。
- 提供一个操作资源的唯一入口点，避免对资源的多重占用（比如写文件操作）。
-
建造者模式
- 意图：有时候面临着”一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定（构建不变，组合常变）
- 优点：
- 建造者独立，易扩展。
- 便于控制细节风险。
-
原型模式
- 意图：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
- 优点：
- 性能提高。
- 逃避构造函数的约束
结构型模式
-
适配器模式
- 意图：将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
- 优点：
- 可以让任何两个没有关联的类一起运行。
- 提高了类的复用。
- 灵活性好。
-
桥接模式
- 意图：实现系统可能有多个角度分类，每一种角度都可能变化，把这种多角度分类分离出来，让它们独立变化，减少它们之间耦合。。
- 使用场景：
- 对于那些不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统，桥接模式尤为适用。
- 如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的继承联系，通过桥接模式可以使它们在抽象层建立一个关联关系
-
装饰器模式
- 意图：创建一个装饰类，用来包装原有的类，并在保持类方法签名完整性和不改变其结构的前提下，提供了额外的功能。
- 优点：装饰类和被装饰类可以独立发展，不会相互耦合，装饰模式是继承的一个替代模式，装饰模式可以动态扩展一个实现类的功能。
- 使用场景：动态增加功能，动态撤销。
-
外观模式
- 意图：隐藏系统的复杂性，并向客户端提供了一个客户端可以访问系统的接口。
- 使用场景：
- 为复杂的模块或子系统提供外界访问的模块。
- 子系统相对独立。
- 预防低水平人员带来的风险。
-
享元模式
- 意图：运用共享技术有效地支持大量细粒度的对象，把其中共同的部分抽象出来，如果有相同的业务请求，直接返回在内存中已有的对象，避免重新创建。
- 实现方法：用唯一标识码判断，如果在内存中有，则返回这个唯一标识码所标识的对象。
- 优点：大大减少对象的创建，降低系统的内存，使效率提高。
-
代理模式
- 意图：为其他对象提供一种代理以控制对这个对象的访问。
- 主要解决：在直接访问对象时带来的问题，比如说：
- 要访问的对象在远程的机器上。在面向对象系统中，有些对象由于某些原因（比如对象创建开销很大，或者某些操作需要安全控制，或者需要进程外的访问）
- 直接访问会给使用者或者系统结构带来很多麻烦，我们可以在访问此对象时加上一个对此对象的访问层。
- 注意事项：
- 和适配器模式的区别：适配器模式主要改变所考虑对象的接口，而代理模式不能改变所代理类的接口。
- 和装饰器模式的区别：装饰器模式为了增强功能，而代理模式是为了加以控制。
行为型模式
-
责任链模式
- 意图：避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。
- 优点:强给对象指派职责的灵活性。通过改变链内的成员或者调动它们的次序，允许动态地新增或者删除责任。
- 使用场景：有多个对象可以处理同一个请求，具体哪个对象处理该请求由运行时刻自动确定。
-
命令模式
- 意图：请求以命令的形式包裹在对象中，并传给调用对象。调用对象寻找可以处理该命令的合适的对象，并把该命令传给相应的对象，该对象执行命令。
- 优点：
- 降低了系统耦合度。
- 新的命令可以很容易添加到系统中去。
-
解释器模式
- 意图：给定一个语言，定义它的文法表示，并定义一个解释器，这个解释器使用该标识来解释语言中的句子(SQL语句)。
- 何时使用：如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。
-
迭代器模式
- 意图：提供一种方法顺序访问一个聚合对象中各个元素,而又无须暴露该对象的内部表示。
- 如何解决：把在元素之间游走的责任交给迭代器，而不是聚合对象，（迭代器作为聚合对象的内部类，方便迭代器访问聚合对象的元素，同时分离迭代器与聚合对象的实现）
- 注意事项：迭代器模式就是分离了集合对象的遍历行为，抽象出一个迭代器类来负责，这样既可以做到不暴露集合的内部结构，又可让外部代码透明地访问集合内部的数据。
-
中介者模式
- 意图：用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
- 优点：各个类之间的解耦，符合迪米特原则。
- 使用场景：系统中对象之间存在比较复杂的引用关系，导致它们之间的依赖关系结构混乱而且难以复用该对象
-
备忘录模式
- 意图：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。
- 优点：
- 给用户提供了一种可以恢复状态的机制，可以使用户能够比较方便地回到某个历史的状态。
- 实现了信息的封装，使得用户不需要关心状态的保存细节。
-
观察者模式
- 意图：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
- 优点：
- 观察者和被观察者是抽象耦合的。
- 建立一套触发机制。
-
状态模式
- 意图：允许对象在内部状态发生改变时改变它的行为，对象看起来好像修改了它的类。
- 使用场景：
- 行为随状态改变而改变的场景。
- 条件、分支语句的代替者。。
-
策略模式
- 意图：义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。
- 如何使用：结合工厂模式，比如通过
“+”，“-”，“*”，“/” 等字符串控制调用相应的函数。
-
模板方法模式
- 意图：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
- 优点：
- 封装不变部分，扩展可变部分。
- 提取公共代码，便于维护。
- 行为由父类控制，子类实现。
-
访问者模式
- 意图：我们使用了一个访问者类，它改变了元素类的执行算法。通过这种方式，元素的执行算法可以随着访问者改变而改变。
- 优点：
- 对象结构中对象对应的类很少改变，但经常需要在此对象结构上定义新的操作。
- 需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免让这些操作”污染”这些对象的类，也不希望在增加新操作时修改这些类。
