设计模式学习总结

本文旨在让大家更好理解每个模式的精髓，相关类图及代码可以自行搜索。

模式的原则：开闭原则（对修改关闭、对扩展开放）、里氏代换原则、依赖倒转原则、接口隔离原则、合成/聚合复用、最少知识原则 共6个。

1、代理模式Proxy:比如修改对象Obj，可以加一个ObjProxy,代理控制了这个对象的权限等；一些前置、后置的检查可以在这里做。

2、单例模式Singleton：比如我想控制一个类在一个JVM中只能创建一个实例，则使用单例模式；

3、工厂模式Factory:比如先定义一个接口IRobot{answer();},再定义工厂接口及类RobotFactory, DbRobotFactory, RedisRobotFactory, 实现类 RobotDbImpl, RobotRedisImpl，这样可以根据情况创建不同的实现类。
4、生成器模式Builder：构造复杂对象；
5、原型模式Prototype：对象的复制（浅复制,深复制）

6、外观模式Facade:：为一个复杂子系统提供一个简单接口，依赖解耦。方便调用者，将我内部的细节进行封装，并解耦。如系统做的下单接口，如商品同步商品中心、价格中心，就是外观模式的应用。

7、适配器模式Adaptor：在OO的过程中，有一些操作对象，不满足现有的接口定义，我们就建立一个Adaptor来将其适配进来。

8、观察者模式Observer：对一个主题，让多个观察者同时监听主题对象，这个主题对象在状态发生变化时，会通知所有观察者对象。用过MQ的应该容易理解。观察者模式定义了一种一对多的依赖关系。

9、策略模式Strategy：定义了一系列的算法，并将每一个算法封装起来，而且使它们还可以相互替换。策略模式让算法独立于使用它的客户而独立变化。（体现了OO基本的多态性）

10、装饰模式Decorator：装饰对象包含一个真实对象的引用(reference).装饰对象把客户请求转发给真实的对象，并在转发这些请求以前或者以后增加一些附加的功能。这样就能确保在运行时，不用修改给定对象结构就可以在外部增加附加的功能。与Proxy的区别，Decorator是在运行时动态确定真实对象的，并且客户是知道具体的真实对象的；而Proxy是对客户是透明的。

11、迭代器模式Iterator：提供遍历集合的简单、统一的方式。java中的Collection，List、Set、Map等，这些集合都有自己的迭代器。

12、责任链模式Chain Of Responsibility：首先交给第一个handler处理，它处理不了则交给nextHandler，如此反复，直到有能处理的handler处理为止，或不能处理为止。适合重构if..elseif..elseif..else的情况。缺点：当责任链比较长时，性能问题比较严重。

13、模板方法模式：先设计好完整的处理问题的框架（类、接口），而具体的算法、业务逻辑实现定义为抽象的、可覆盖的方法，由具体的业务实现者完成。目的是先将完整的流程串起来，之后再逐步具体实现。记得在线客服项目，阿超就是写好了聊天参与者的接口，我具体负责机器人应答实现的。

14、备忘录模式：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。以后随时可以恢复该对象的状态。

15、解释器模式Interpreter：解析文法用，用的比较少。

16、命令模式Command：Command是遥控器按钮，Receiver是电视机，Invoker是遥控器。

17、访问者模式：修改、扩展一个类不是直接修改它的方法，而是修改它的访问者的方法（关系不大且易变），保证该对象的稳定，并符合单一职责原则。元素类可以通过接受不同的访问者实现扩展。

18、桥接Bridge模式：一个业务对象，具有两个或两个以上的维度变化。通过对象组合的方式，Bridge 模式把两个角色之间的继承关系改为了耦合的关系，从而使这两者可以从容自若的各自独立的变化，这也是Bridge模式的本意。

19、组合模式：将组合为树形结构的对象，按照统一的方式进行操作（递归遍历），包括叶子节点和复合节点（非叶子节点）。

20、享元模式：享元模式采用对象共享的做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力。

21、中介模式：把大量对象间的错综复杂的联系（耦合），变成“星形结构”。由原来的网状结构到星形结构的转变，可以理解为就是中介者模式的作用。

22、状态模式：将对象的状态改变，实现为该对象的实现类的改变。从而使相关依赖于状态的操作简单化，OO化。

引用下别人说的：

对于一个场合到底用不用模式，这对所有的开发人员来说都是一个很纠结的问题。有时候，因为预见到需求上会发生的某些变化，为了系统的灵活性和可扩展性而使用了某种设计模式，但这个预见的需求偏偏没有，相反，没预见到的需求倒是来了不少，导致在修改代码的时候，使用的设计模式反而起了相反的作用，以至于整个项目组怨声载道。这样的例子，我相信每个程序设计者都遇到过。所以，基于敏捷开发的原则，我们在设计程序的时候，如果按照目前的需求，不使用某种模式也能很好地解决，那么我们就不要引入它，因为要引入一种设计模式并不困难，我们大可以在真正需要用到的时候再对系统进行一下，引入这个设计模式。