设计模式

一、创建模式
1.工厂方法：一个工厂通过方法创建多个产品
2.抽象工厂方法：多个工厂创建多个产品族
3.建造者模式：分解构建步骤，分步构建
4.原型模式：一个对象需要多次修改部分值，利用克隆实现
5.单例模式：只要一个实例，减少系统开销

二、结构模式
6.适配器模式：重构时，不修改已有模块，增加适配器来协调2个模块工作
7.桥接模式：开发时，jdbc,需要增加桥对象，可切换对接对象，实现不同桥功能
8.组合模式：开发时，组织机构，文档结构
9.装饰器模式：重构时，不修改已有模块，对已有模块功能进行扩展
10.外观模式：开发重构
11.享元模式：开发时，创建对象池，共享对象，减少系统开销
12.代理模式：重构时，代理目标对象执行，主要是控制目标对象方式是否执行

三、行为模式
13.责任链模式：审批流
14.命令模式：浏览器的请求方式，封装请求，分离请求者与接收者
15.解释器模式：表达式解析
16.迭代器模式：迭代器
17.备忘录模式：ghost，保存当前对象状态，用于恢复
18.中介者模式：QQ，多个构件间通信的枢纽
19.观察者模式：消息通知，广播机制，通过注册接收者，观察者发消息给多个接收者
20.状态模式：针对对象切换，将状态封装成对象，通过切换状态来用不同状态对象实现相同方法。
21.策略模式：针对方法切换，对某个方法进行切换，实现不同的实现方式。
22.模板方法模式：sitmesh，tiles,freemarker就是类似装饰模式，只不过如同模板一般，只需要关注变动的地方即可
23.访问者模式：利用多态特性
————————————————

 原文链接：https://blog.csdn.net/kimheesunliulu/article/details/99693009

 

1.单例模式：

应用场景

• 整个程序的运行中只允许有一个类的实例

• 频繁实例化然后销毁的对象

• 创建对象时耗时过多或者耗资源过多，但又经常用到的对象

• 封装一些常用的工具类
• 保存一些共享数据在内存中，其他类随时可以读取

优点

1.实现了整个程序对唯一实例访问的控制。
2.因为单例要求程序只能有一个对象，所以对于那些需要频繁创建和销毁的对象来说可以提高系统的性能，并且可以节省内存空间。
3.可以全局访问。
4.允许可变数目的实例。

缺点

1. 不适用于变化频繁的对象。
2.符合的场景有限。
3.如果实例化的对象长时间不被利用，系统会认为该对象是垃圾而被回收，可能会导致对象状态的丢失
4.可扩展性较差。

UML图（转自https://blog.csdn.net/It_sharp/article/details/82147111）

 

2.动态代理

应用场景

• 统计每个 api 的请求耗时
• 统一的日志输出
• 校验被调用的 api 是否已经登录和权限鉴定
• Spring的 AOP 功能模块就是采用动态代理的机制来实现切面编程

优点

缺点

UML图

3.工厂模式

应用场景

工厂方法模式应用场景：
1.类不知道自己要创建哪一个对象
2.类用它的子类来指定创建哪个对象
3.客户需要清楚创建了哪一个对象
4.一个抽象产品类，可以派生出多个具体产品类。   
5.一个抽象工厂类，可以派生出多个具体工厂类。   
6.每个具体工厂类只能创建一个具体产品类的实例。
抽象工厂模式：
1.系统需要屏蔽有关对象如何创建、如何组织和如何表示
2.系统需要由关联的多个对象来构成
3.有关联的多个对象需要一起应用并且他们的约束是强迫的（不可分离）
4.你提供一组对象而不显示它们的实现过程，只显示它们的接口。
5.多个抽象产品类，每个抽象产品类可以派生出多个具体产品类。   
6.一个抽象工厂类，可以派生出多个具体工厂类。   
7.每个具体工厂类可以创建多个具体产品类的实例。   
    
区别：
工厂方法模式只有一个抽象产品类，而抽象工厂模式有多个。   
工厂方法模式的具体工厂类只能创建一个具体产品类的实例，而抽象工厂模式可以创建多个。 

优点（转自https://blog.csdn.net/Fly_as_tadpole/article/details/88326807）

简单工厂模式：工厂类含有必要的判断逻辑，可以决定在什么时候创建哪一个产品类的实例，客户端可以免除直接创建产品对象的责任，而仅仅"消费"产品。简单工厂模式通过这种做法实现了对责任的分割。简单工厂模式能够根据外界给定的信息，决定究竟应该创建哪个具体类的对象。通过它，外界可以从直接创建具体产品对象的尴尬局面中摆脱出来。外界与具体类隔离开来，偶合性低。明确区分了各自的职责和权力，有利于整个软件体系结构的优化。                 

工厂方法模式：工厂方法模式是为了克服简单工厂模式的缺点（主要是为了满足OCP）而设计出来的。简单工厂模式的工厂类随着产品类的增加需要增加很多方法（或代码），而工厂方法模式每个具体工厂类只完成单一任务，代码简洁。工厂方法模式完全满足OCP，即它有非常良好的扩展性。                    

抽象工厂模式：抽象工厂模式主要在于应对“新系列”的需求变化。分离了具体的类，抽象工厂模式帮助你控制一个应用创建的对象的类，因为一个工厂封装创建产品对象的责任和过程。它将客户和类的实现分离，客户通过他们的抽象接口操纵实例，产品的类名也在具体工厂的实现中被分离，它们不出现在客户代码中。它使得易于交换产品系列。一个具体工厂类在一个应用中仅出现一次——即在它初始化的时候。这使得改变一个应用的具体工厂变得很容易。它只需改变具体的工厂即可使用不同的产品配置，这是因为一个抽象工厂创建了一个完整的产品系列，所以整个产品系列会立刻改变。它有利于产品的一致性。当一个系列的产品对象被设计成一起工作时，一个应用一次只能使用同一个系列中的对象，这一点很重要，而抽象工厂很容易实现这一点。抽象工厂模式有助于这样的团队的分工，降低了模块间的耦合性，提高了团队开发效率。      
 

缺点（转自https://blog.csdn.net/Fly_as_tadpole/article/details/88326807）

简单工厂模式：当产品有复杂的多层等级结构时，工厂类只有自己，以不变应万变，就是模式的缺点。因为工厂类集中了所有产品创建逻辑，一旦增加产品或者删除产品，整个系统都要受到影响。系统扩展困难，一旦添加新产品就不得不修改工厂逻辑，有可能造成工厂逻辑过于复杂,违背了"开放--封闭"原则(OCP).另外，简单工厂模式通常使用静态工厂方法，这使得无法由子类继承，造成工厂角色无法形成基于继承的等级结构。                 

工厂方法模式：假如某个具体产品类需要进行一定的修改，很可能需要修改对应的工厂类。当同时需要修改多个产品类的时候，对工厂类的修改会变得相当麻烦。比如说，每增加一个产品，相应的也要增加一个子工厂，会加大了额外的开发量。                  

抽象工厂模式：抽象工厂模式在于难于应付“新对象”的需求变动。难以支持新种类的产品。难以扩展抽象工厂以生产新种类的产品。这是因为抽象工厂几乎确定了可以被创建的产品集合，支持新种类的产品就需要扩展该工厂接口，这将涉及抽象工厂类及其所有子类的改变。 
 

UML图

4.责任链模式

应用场景

优点

缺点

UML图