设计模式知识概括

设计模式概述

设计模式层次：

• 第 1 层： 刚开始学编程不久， 听说过什么是设计模式
• 第 2 层： 有很长时间的编程经验， 自己写了很多代码， 其中用到了设计模式， 但是自己却不知道
• 第 3 层： 学习过了设计模式， 发现自己已经在使用了， 并且发现了一些新的模式挺好用的
• 第 4 层： 阅读了很多别人写的源码和框架， 在其中看到别人设计模式， 并且能够领会设计模式的精妙和带来的好处。
• 第 5 层： 代码写着写着， 自己都没有意识到使用了设计模式， 并且熟练的写了出来。

设计模式介绍：

• 设计模式是程序员在面对同类软件工程设计问题所总结出来的有用的经验， 模式不是代码， 而是某类问题的通用解决方案， 设计模式（Design pattern） 代表了最佳的实践。 这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。
• 设计模式的本质提高软件的维护性， 通用性和扩展性， 并降低软件的复杂度。
• 《设计模式》是经典的书， 作者是 Erich Gamma、 Richard Helm、 Ralph Johnson 和 John Vlissides Design（俗称 “四人组 GOF” ）
• 设计模式并不局限于某种语言， java， php， c++ 都有设计模式。
• 链接：23种设计模式全面解析

设计模式类型：

• 设计模式分为三种类型， 共 23 种
• 创建型模式： 单例模式、 抽象工厂模式、 原型模式、 建造者模式、 工厂模式。
• 结构型模式： 适配器模式、 桥接模式、 装饰模式、 组合模式、 外观模式、 享元模式、 代理模式。
• 行为型模式： 模版方法模式、 命令模式、 访问者模式、 迭代器模式、 观察者模式、 中介者模式、 备忘录模式、解释器模式（Interpreter 模式） 、 状态模式、 策略模式、 职责链模式(责任链模式)。

常用设计模式

观察者模式：

• 观察者模式角色分为：
  ①事件：封装了事件源对象及跟事件相关的信息。
  ②事件监听器：当事件源的属性或状态改变时,取得相应的监听器调用其内部的回调方法。对每个明确的事件的发生，都相应地定义一个明确的Java方法。
  ③事件源：事件发生的地方，由于事件源的某项属性或状态发生了改变(比如BUTTON被单击、TEXTBOX的值发生改变等等)导致某项事件发生。换句话说就是生成了相应的事件对象。因为事件监听器要注册在事件源上,所以事件源类中应该要有盛装监听器的容器(List,Set等等)。
• 观察者模式使用场景：
  ①关联行为场景。需要注意的是，关联行为是可拆分的，而不是“组合”关系。
  ②事件多级触发场景。当一个对象在不知道对方具体是如何实现时需要通知其它对象。
  ③跨系统的消息交换场景，如消息队列的处理机制。
  ④当一个对象改变需要通知不确定数的对象时
• 实际设计：
  ①事件的全类名与对应的key存到数据库。
  ②一个模块中触发时，在数据库中通过对应的key在数据库中获取相应事件的全类名，然后通过反射判断是否是相应的事件接口，若是则调用对应的方法。

状态模式与策略模式与命令模式的区别：

• 设计模式中有三个模式State, Command,Strategy，这三种设计模式都是行为型设计模式，在结构上又都很像，所以很多时候分不清楚。
• 区分这三种模式不要focus在结构上，这三种模式最主要是在使用意图上有区别：
  ①状态模式：内部维护一个状态，会随着public api的调用进行相应的状态转移。外界不需要知道状态及其变化情况。
  ②命令模式：根据客户的请求封装相应的命令，处理者就不用care这个命令是什么，该怎么处理。只用去调用统一的execute接口即可，当然不同的命令有不同的接口名称，也可以不叫execute。
  ③策略模式：你有很多不同的算法，所以你可以封装算法，使用者执行相同的功能，但是使用不同的方法。这就是策略。
• 打个比喻就是： 命令模式等于菜单中的复制，移动，压缩等，而策略模式是其中一个菜单的例如复制到不同算法实现。

工厂模式+策略模式+模板设计模式：

• 最常见的是这种场景：
  
• 示意图就是这样，当然实际情况要复杂得多。例如我这有个银行卡签约的逻辑，操作A/B/C基本一样，但是操作D按照业务模式分出了D1/D2/D3/D4四种情况。所以完整业务就写了个模板，ABC操作在模板类中定义，D操作按业务模式不同分了四个子类，也可以理解为四个策略类。分了子类之后，就需要有一个地方/类来判断什么时候用哪个子类。这时候就需要工厂了。因为我个人习惯把工厂放到接口下，所以也把这种工厂类叫做分发类。
• 总的下来这套逻辑的类结构大概就是这样的：
  

责任链模式或者装饰者模式：

• 有时候不同的业务线的业务逻辑会是这样的：
  
• 这种时候用模板就不如用责任链或者装饰者了。例如我正在做的一个查用户信息的例子，某接口在基本信息基础上还要查用户绑定的银行卡的信息，另一个接口则不需要银行卡信息、但是要最近成交的三笔订单的信息，还有个接口不仅要银行卡信息、还要银行卡更历史记录……于是我就用了个责任链，把每个操作独立成链中的一环，谁要什么信息自己拼起来就好了。、
• 个人习惯上，如果各操作之间是完全独立的，那就用责任链；如果有依赖关系，那还是用装饰者吧。类结构大概是这样的：