【设计模式从入门到精通】设计模式对比
目录
设计模式对比
1、抽象工厂模式 VS 建造者模式 VS 模板方法模式
首先，看下各个模式的定义
- 抽象工厂模式：由工厂对象决定创建出哪种产品类的实例
- 建造者模式：将复杂对象的建造过程抽象出来，使这个抽象过程的不同实现方法可以构造出不同表现（属性）的对象
- 模板方法模式：定义一个操作中的算法骨架，将一些步骤延迟到子类中。分为类行为模式和对象行为模式，前者采用继承机制来在类间分派行为，后者采用组合或聚合在对象间分配行为
通过一张表格总结其区别
| 抽象工厂模式 | 建造者模式 | 模板方法模式 |
|---|---|---|
| 创建型模式 | ~ | 结构型模式 |
| 关注的是对象的创建 | 关注的是对象的创建 | 关注的是对象的方法结构 |
| 关注的是具体产品的创建 | 关注的是复杂对象的建造过程 | 关注的是算法框架 |
| 产品之间一般无关系 | 建造过程有关系，这些建造过程都是为创建一个复杂对象服务的，最终要到指挥者中进行组装，生成一个对象 | 各个算法之间有关系，模板类中定义好了算法骨架，具体算法在子类中实现 |
2、适配器模式 VS 桥接模式
首先，看下两个设计模式的定义
- 适配器模式：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作
- 桥接模式：将抽象与实现分离，使它们可以独立变化
通过一张表格总结其区别
| 适配器模式 | 桥接模式 |
|---|---|
| 结构型模式 | ~ |
| 一种接口转换成另一种接口 | 实现与接口分开，可以独立变化 |
| 基类继承+接口实现 | 接口组合 |
3、外观模式 VS 代理模式 VS 命令模式
首先，看下各个设计模式的定义
- 外观模式：通过为多个复杂的子系统提供一个一致的接口，而使这些子系统更加容易被访问
- 代理模式：由于某些原因需要给某对象提供一个代理以控制对该对象的访问
- 命令模式：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开
通过一张表格总结其区别
| 外观模式 | 代理模式 | 命令模式 |
|---|---|---|
| 结构型模式 | ~ | 行为型模式 |
| 为子系统一组接口提供一个统一的高层接口 | 强调的是代替本人作业，减少对实际对象的操作 | 请求和执行分割开 |
| 通过组合聚合 | 通过组合聚合+接口实现 | 通过组合聚合 |
| 外观类不需要对被包装类中方法都使用到 | 代理类需要对被代理类中方法都实现 | 命令者不需要对接收者中方法都使用到 |
| 外观类可以包装多个类 | 代理类只代理一个类 | 一个命令者只执行一个请求，一个接收者可对应多个命令者 |
4、观察者模式 VS 中介者模式
首先，看下两个设计模式的定义
- 观察者模式：指多个对象间存在一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新
- 中介者模式：定义一个中介对象来封装一系列对象之间的交互，使原有对象之间的耦合松散，且可以独立地改变它们之间的交互
通过一张表格总结其区别
| 观察者模式 | 中介者模式 |
|---|---|
| 行为型模式 | ~ |
| 强调观察者改变时统一的通知 | 强调同事类之间的交互 |
| 观察者都会收到消息 | 同事类可以有选择进行交互 |
| 处理逻辑在发送方 | 处理逻辑在中介者 |
| 观察者和被观察者分离 | 同事类之间交互解耦 |
5、策略模式 VS 状态模式
首先，看下两个设计模式的定义
- 策略模式：该模式定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的变化不会影响使用算法的客户
- 状态模式：对有状态的对象，把复杂的“判断逻辑”提取到不同的状态对象中，允许状态对象在其内部状态发生改变时改变其行为
通过一张表格总结其区别
| 策略模式 | 状态模式 |
|---|---|
| 行为型模式 | ~ |
| 多个类区别不同的行为（算法） | 多个类区别不同的状态 |
| 一组方案或算法的相互替换，采取何种策略由外部条件决定 | 主要解决复杂逻辑处理的状态迁移，这个过程由对象内部条件决定 |
| 策略类不依赖上下文 | 状态类依赖上下文 |
6、策略模式 VS 模板方法模式
首先，看下两个设计模式的定义
- 策略模式：该模式定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的变化不会影响使用算法的客户
- 模板方法模式：定义一个操作中的算法骨架，而将算法的一些步骤延迟到子类中，使得子类可以不改变该算法结构的情况下重定义该算法的某些特定步骤
通过一张表格总结其区别
| 策略模式 | 模板方法模式 |
|---|---|
| 行为型模式 | ~ |
| 采取何种策略由外部决定 | 采用何种实现由外部决定 |
| 定义一系列算法并封装，可相互替换，独立于客户变化 | 定义算法骨架，将一些步骤延迟到子类实现 |
| 利用多态 | 利用继承 |
| 偏重于解决算法多样性对代码结构冲击的问题 | 侧重于业务流程复杂但稳定（整体算法结构不变），而其中某些步骤变化相对剧烈（一些步骤的具体实现不同） |
