3.0 设计模式汇总

设计模式汇总

0.设计模式的使用目的

技术永远为业务服务,设计模式是基于业务来选择使用的,它是实现七大设计原则的具体方式,目的是让程序高内聚，低耦合，易扩展，易复用，易维护。我们需要掌握每种设计模式的应用场景、特征、优缺点、及每种设计模式的关联关系,在有实际架构需求后，判断它符合某类设计模式再使用，以满足日常业务需求。

1.代码重用性(即:相同功能的代码提取出来,不用多次编写)

2.可读性(即: 编写程序时规范书写,便于其他程序员的阅读和理解)

3.可扩展性(即: 方便扩展增加新功能,也称为可维护)

4.可靠性(即: 当我们增加新的功能后,对原有功能没有影响,使程序呈现高内聚,低耦合的特性)

面向对象 ==> 功能模块[设计模式 + 算法(数据结构)] ==> 框架[使用到多种设计模式] ==> 架构[服务器集群]

1.需求驱动

不仅仅是功能性需求，需求驱动还包括性能和运行时的需求，如软件的可维护性和可复用性等方面。设计模式是针对软件设计的，而软件设计是针对需求的，一定不要为了使用设计模式而使用，否则可能会使设计变的复杂，使软件难以调试和维护；

2.分析成功的模式应用项目

对现有的应用实例进行分析是一个很好的学习途径，应当注意学习已有的向目，而不仅是学习设计模式如何实现，

更重要的是注意在什么场合使用设计模式。

3.充分了解所使用的开发平台

设计模式大部分都针对面向对象的软件设计，因此在理论上适合任何面向对象的语言，但随着技术的发展和编程环境的改善，

设计模式的实现方式会有很大的差别，在一下平台下，某些设计模式是自然实现的。

不仅指编程语言，还包括平台引入的技术，例如 Java EE 引入了反射机制和依赖注入，这些技术的使用使设计模式的实现方式产生了改变；

4.在编程中领悟模式

软件开发是一项实践工作，最直接的方法就是编程，掌握设计模式，除了理论还需要大量的实践积累，才可能会“渐悟” 或 “顿悟”；

5.避免设计过度

设计模式解决的是设计不足的问题，但同时也要避免设计过度，一定要牢记简洁原则，设计模式是为了让设计更简单而不是更复杂；

这里需要把握需求变化的程度，一定要区分需求的稳定部分和可变部分，一个软件必然有稳定部分，该部分是核心业务逻辑，如果核心业务逻辑发生变化，软件就没有存在的必要，核心业务逻辑是我们需要固化的，对可变的部分，要判断可能发生变化的程度来确定设计策略和设计风险，要知道，设计过度和设计不足同样对项目有害；

6.设计模式汇总表

我们已经学习完了经典的 23 种设计模式。下面总结一下这 23 种设计模式，以方便日后复习和查阅。

分类	设计模式	简述	一句话归纳	目的	生活案例
创建型设计模式 (用于对象的创建）	工厂模式 (Factory）	不同条件下创建不同实例	产品标准化，生产更高效	封装创建细节	实体工厂
	单例模式(Singleton)	保证一个类仅有一个实例,并且提供一个全局访问点	世上只有一个我	保证独一无二	CEO
	原型模式 (Prototype)	通过拷贝原型创建新的对象	拔一根猴毛，吹出千万个	高效创建对象	克隆
	建造者模式 (Builder）	用来创建复杂的复合对象	高配中配和低配，想选哪配就哪配	开放个性配置步骤	选配
结构型设计模式 (类和对象的组合)	代理模式（Proxy）	为其他对象提供一种代理以控制对这个对象的访问	没有资源没时间，得找别人来帮忙	增强职责	媒婆
	外观模式（Facade）	对外提供一个统一的接口用来访问子系统	打开一扇门，通向全世界	统一访问入口	前台
	装饰器模式（Decorator）	为对象添加新功能	他大舅他二舅都是他舅	灵活扩展、同宗同源	煎饼
	享元模式（Flyweight）	使用对象池来减少重复对象的创建	优化资源配置，减少重复浪费	共享资源池	全国社保联网
	组合模式（Composite）	将整体与局部(树形结构)进行递归,让客户端能以同一种方式对其进行处理	人在一起叫团伙，心在一起叫团队	统一整体和个体	组织架构树
	适配器模式（Adapter）	将原来不兼容的两个类融合在一起	万能充电器	兼容转换	电源适配
	桥接模式（Bridge）	将两个能够独立变化的部分分离开来	约定优于配置	不允许用继承	桥
行为型设计模式 (对象之间的通信）	模板模式（Template）	定义一套流程模板，根据需要实现模板中的操作	流程全部标准化，需要微调请覆盖	逻辑复用	把大象进冰箱
	策略模式（Strategy）	封装不同的算法，算法之间能互相替换	条条大道通罗马，具体哪条你来定	把选择权交给用户	选择支付方式
	责任链模式 (C of R pattern)	拦截的类都实现统一接口，每个接收者都包含对下一个接收者的引用。将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。	各人自扫门前雪，莫管他们瓦上霜	解耦处理逻辑	踢皮球
	迭代器模式（Iterator）	提供一种方法顺序访问一个聚合对象中的各个元素	流水线上坐一天，每个包裹扫一遍	统一对集合的访问方式	逐个检票进站
	命令模式（Command）	将请求封装成命令，并记录下来，能够撤销与重做	运筹帷幄之中，决胜千里之外	解耦请求和处理	遥控器
	状态模式（State）	根据不同的状态做出不同的行为	状态驱动行为，行为决定状态	绑定状态和行为	订单状态跟踪
	备忘录模式（Memento）	保存对象的状态，在需要时进行恢复	失足不成千古恨，想重来时就重来	备份、后悔机制	草稿箱
	中介者模式（Mediator）	将对象之间的通信关联关系封装到一个中介类中单独处理，从而使其耦合松散	联系方式我给你，怎么搞定我不管	统一管理网状资源	朋友圈
	解释器模式（Interpreter）	定义一个语言,并定义该语言的文法表示,在设计一个解释器来解释语言中的句子	我想说”方言“，一切解释权都归我	实现特定语法解析	摩斯密码
	观察者模式（Observer）	状态发生改变时通知观察者，一对多的关系	到点就通知我	解耦观察者与被观察者	闹钟
	访问者模式（Visitor）	稳定数据结构，定义新的操作行为	横看成岭侧成峰，远近高低各不同	解耦数据结构和数据操作	KPI考核
	委派模式（Delegate）	允许对象组合实现与继承相同的代码重用，负责任务的调用和分配	这个需求很简单，怎么实现我不管	只对结果负责	授权委托书