# design-pattern

**Repository Path**: TheKernel/design-pattern

## Basic Information

- **Project Name**: design-pattern
- **Description**: Java设计模式
- **Primary Language**: Java
- **License**: AFL-3.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2020-01-31
- **Last Updated**: 2020-12-19

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 设计模式
<span style="color: gray;">*表示不常用</span>   

## 7大设计原则

### 1. 开闭原则(open close)

**定义** 

    一个软件实体如类、模块和函数应该对扩展开放，对修改关闭
    （用抽象构建框架，对实现扩展细节）

**优点** 

    1. 提高软件系统的可复用性及可维护性

#### UML图
![开闭原则](images/开闭原则.png)

### 2. 依赖倒置原则(dependence inversion)

**定义** 

    高层模块不应该依赖底层模块，二者都应该依赖其抽象
    （抽象不应该依赖细节，细节应该依赖抽象、
    针对接口编程，不要针对实现编程）

**优点** 

    1. 可以减少类间的耦合性
    2. 提高系统稳定性
    3. 提高代码可读性和可维护性
    4. 可降低修改程序所造成的风险

#### UML图
![依赖倒置原则](images/依赖倒置原则.png)

### 3.单一职责原则(single responsibility)

**定义** 

    不要存在多于一个导致类变更的原因
    （一个类、接口、方法只负责一项职责）

**优点** 

    1. 降低类的复杂度
    2. 提高类的可读性
    3. 提高系统的可维护性
    4. 降低变更引起的风险

#### UML图
![单一职责原则](images/单一职责原则.png)

### 4.接口隔离原则(interface segregation)

**定义** 

    用多个专门的接口，而不是用单一的总接口，客户端不应该依赖它不需要的接口
    1. 一个类对一个类的依赖应该建立在最小接口上
    2. 建立单一接口，要建立庞大臃肿的接口
    3. 尽量细化接口，接口中的方法尽量少
    4. 注意适度原则，一定要适度

#### UML图
![接口隔离原则](images/接口隔离原则.png)

### 5.迪米特原则(demeter)

**定义** 

    一个对象应该对其他对象保持最少的了解。又叫最少知道原则
    （尽量降低类与类之间的耦合）

**优点** 
    
    1. 降低类之间的耦合

#### UML图
![迪米特原则](images/迪米特原则.png)

## 创建型设计模式

### 1.简单工厂(simple factory)

**定义** 

    由一个工厂对象决定创建出哪一种产品类的实例

**类型** 
    
    创建型, 但不属于GOF23种设计模式

**适用场景** 

    1. 工厂类负责创建的对象比较少
    2. 客户端（应用层）只知道传入工厂类的参数，对于如何创建对象（逻辑）
        不关心

**优点** 

    1. 只需要传入一个正确的参数，就可以获取你所需要的对象而无须知道其创建细节

**缺点** 

    1. 工厂类的职责相对过重，增加新的产品需要修改工厂类的判断逻辑，违背开闭原则

#### UML图
![简单工厂设计模式](images/简单工厂.png)

### 2.工厂方法(factory method)

**定义** 

    定义一个创建对象的接口，但让实现这个接口的类来决定实例化哪个类，工厂方法让类的实例化推迟到子类中进行

**类型** 

    创建型

**适用场景**

    1. 创建对象需要大量重复的代码
    2. 客户端（应用层）不依赖于产品实例如何被创建、实现等细节
    3. 一个类通过其子类来指定创建哪个对象

**优点**

    1. 用户只需关心所需产品对应的工厂，无需关系创建细节
    2. 加入新产品符合开闭原则，提高可扩展性

**缺点**

    1. 类的个数容易过多，增加复杂度
    2. 增加了系统的抽象性和理解难度

#### UML图
![工厂方法设计模式](images/工厂方法.png)

### 3. 抽象工厂(abstract factory)

**定义** 

    抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口（无须指定它们具体的类）

**类型** 

    创建型

**适用场景**

    1. 客户端（应用层）不依赖于产品类实例如何被创建、实现等细节
    2. 强调一系列相关的产品对象（属于同一产品族）一起使用创建对象需要大量重复代码
    3. 提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于具体实现

**优点** 

    1. 具体产品在应用层代码隔离，无须关心创建细节
    2. 将一个系列的产品族统一到一起创建

**缺点**

    1. 规定了所有可能被创建的产品集合，产品族中扩展新的产品困难，需要修改抽象工厂的接口
    2. 增加了系统的抽象性和理解难度

#### UML图
![抽象工厂设计模式](images/抽象工厂.png)

### 4.建造者模式(builder)

**定义** 

    将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示（用户只需指定需要创建的类型就可以得到它们，建造过程及细节不需要知道）

**类型** 

    创建型

**适用场景**

    1. 如果一个对象有非常复杂的内部结构（很多属性）
    2. 想把复杂对象的创建和使用分离

**优点**

    1. 封装性好，创建和使用分离
    2. 扩展性好、建造类之间独立、一定程度上解耦

**缺点**

1. 产生多余的Builder对象
2. 产品内部发生变化，建造者都要修改，成本较大

#### UML图(普通建造者模式)
![建造者设计模式](images/普通建造者.png)
#### UML图(链式建造者模式)
![建造者设计模式](images/链式建造者.png)

### 5.单例模式(singleton)

**定义** 

    保证一个类仅有一个实例，并提供全局访问点

**类型** 

    创建型

**优点**

    1. 在内存中只有一个实例，减少了内存开销
    2. 可以避免对资源的多重占用
    3. 设置全局访问点，严格控制访问

**缺点**

    1. 没有接口，扩展困难

**重点**

    1. 私有构造器
    2. 线程安全
    3. 延迟加载
    4. 序列化和反序列化安全
    5. 反射

**实用技能**

    1. 反编译
    2. 内存原理
    3. 多线程Debug
        在 IDEA 中打断点，并右键选择Thread

**相关设计模式**

    1. 工厂模式
    2. 享元模式

#### DoubleCheck问题

**问题：** 

    new 对象时可能发生重排序

**解决：** 

    使用 volatile 关键字
![DoubleCheck问题](images/单例模式/DoubleCheck问题.png)

#### 静态内部类

![静态内部类](images/单例模式/静态内部类.png)

### *6.原型模式(prototype)

**定义** 

    指原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象
    （不需要知道任何创建细节，不调用构造函数）

**类型** 
    
    创建型

**适用场景**

    1. 类初始化消耗较多资源
    2. new产生的一个对象需要非常繁琐的过程（数据准备、访问权限等）
    3. 构造函数比较复杂
    4. 循环体中生产大量对象时

**优点**

    1. 原型模式性能比直接new一个对象性能高
    2. 简化创建过程

**缺点**

    1. 必须配备克隆方法
    2. 对克隆复杂对象或对克隆出的对象进行复杂改造时，容易引入风险
    3. 深拷贝、浅拷贝要运用得当

**扩展**

    1. 深克隆
    2. 浅克隆

**常见问题**

    1. 单例模式下类若要实现Cloneable接口clone方法需返回getInstance()

## 结构型设计模式

### 7.外观模式(facade)

**定义** 

    又叫门面模式，提供了一个统一的接口，用来访问子系统中的一群接口
    （外观模式定义了一个高层接口，让子系统更容易使用）

**类型**
    
    结构型
    
**适用场景**

    1. 子系统越来越复杂，增加外观模式提供简单调用接口
    2. 构建多层系统结构，利用外观对象作为每层的入口，简化层间调用
    
**优点**
    
    1. 简化了调用过程，无需了解深入子系统，防止带来风险
    2. 减少系统依赖、松散耦合
    3. 更好的划分访问层次
    4. 符合迪米特原则，即最少知道原则
    
**缺点**

    1. 增加子系统、扩展子系统行为容易引入风险
    2. 不符合开闭原则
    
**相关设计模式**

    1. 中介者模式
    2. 单例模式
    3. 抽象工厂模式

### 8. 装饰者模式(decorator)

**定义**
    
    在不改变原有对象的基础上，将功能附加到对象上
    提供了比继承更有弹性的替代方案
    （扩展原有对象功能）
    
**类型**

    结构型

**适用场景**

    1. 扩展一个类的功能或给一个类添加附加职责
    2. 动态的给一个对象添加功能，这些功能可以再动态撤销
    
**优点**

    1. 继承的有力补充，比继承灵活，不改变原有对象的情况下给一个对象扩展功能
    2. 通过使用不同装饰类以及这些装饰类的排列组合，可以实现不同效果
    3. 符合开闭原则
    
**缺点**

    1. 会出现更多的代码，更多的类，增加程序复杂性
    2. 动态装饰时，多层装饰时会更复杂
    
**相关设计模式**

    1. 代理模式
    2. 适配器模式
    
#### UML图

![装饰者模式](images/装饰者模式.png)

### 9. 适配器模式(adapter)

**定义** 
    
    将一个类的接口转换成客户期望的另一个接口
    使原本接口不兼容的类可以一起工作
    
**类型**

    结构型
    
**适用场景**

    1. 已经存在的类，它的方法和需求不匹配时（方法结果相同或相似）
    2. 不是软件设计阶段考虑的设计模式，是随着软件维护，由于不同产品、不同厂家造成功能类似而接口不相同情况下的解决方案
    
**优点**

    1. 能提高类的透明性和服用，现有的类复用但不需要改变
    2. 目标类和适配器类解耦，提高程序扩展性
    3. 符合开闭原则
    
**缺点**

    1. 适配器编写过程需要全面考虑，可能会增加系统的复杂性
    2. 增加系统代码可读的难度
    
**扩展**

    1. 对象适配器
    2. 类适配器
    
**相关设计模式**

    1. 外观模式
   
#### 对象适配器UML图
![对象适配器](images/适配器模式/对象适配器.png)

#### 类适配器UML图
![类适配器](images/适配器模式/类适配器.png)

### *10. 享元模式(flyweight)

**定义**

    提供了减少对象数量从而改善应用所需的对象结构的方式
    运用共享技术有效地支持大量细粒度的对象

**类型**

    结构型
    
**适用场景**

    1. 常常应用于系统底层的开发，以便解决系统的性能问题
    2. 系统有大量类似对象、需要缓冲池的场景
    
**优点**

    1. 减少对象的创建，降低内存中对象的数量，降低系统的内存，提高效率
    2. 减少内存之外的其他资源占用
    
**缺点**

    1. 关注内/外部状态、关注线程安全问题
    2. 使系统、程序的逻辑复杂化
    
**扩展**

    1. 内部状态(不随外部环境变化而改变)
    2. 外部状态
    
**相关设计模式**

    1. 代理模式
    2. 单例模式(容器单例)

### *11. 组合模式(composite)

**定义**

    将对象组合成树形结构以表示成"部分-整体"的层次结构
    组合模式使客户端对单个对象和组合对象保持一致的方式处理

**类型**

    结构型

**适用场景**

    1. 希望客户端可以忽略组合对象与单个对象的差异时
    2. 处理一个树形结构时

**优点**

    1. 清楚地定义分层次的复杂对象，表示对象的全部或部分层次
    2. 让客户端忽略了层次的差异，方便对整个层次结构进行控制
    3. 简化客户端代码
    4. 符合开闭原则

**缺点**

    1. 限制类型时会较为复杂
    2. 使设计变得更加抽象
    
**相关设计模式**

    1. 访问者模式
    
### *12. 桥接模式(bridge)

**定义**

    将抽象部分与它的具体实现部分分离，使它们都可以独立地变化
    通过组合的方式建立两个类之间联系，而不是继承
    
**类型**

    结构型
    
**适用场景**

    1. 抽象与具体实现之间增加更多的灵活性
    2. 一个类存在两个（或多个）独立变化的维度，且这两个（多个）维度都需要独立进行扩展
    3. 不希望使用继承，或因为多层继承导致系统类的个数剧增

**优点**

    1. 分离抽象部分及其具体实现部分
    2. 提高了系统的可扩展性
    3. 符合开闭原则
    4. 符合合成复用原则

**缺点**

    1. 增加了系统的理解与设计难度
    2. 需要正确地识别出系统中两个独立变化的维度

**相关设计模式**

    1. 组合模式
    2. 适配器模式

#### UML图
![桥接模式](images/桥接模式.png)

## 行为型设计模式

### 13.模板方法(template method)

**定义**

    定义了一个算法的骨架，并允许子类为一个或多个步骤提供实现
    模板方法使得子类可以在不改变算法结构的情况下，重新定义算法的某些步骤

**类型**

    行为型

**适用场景**

    1. 一次性实现一个算法的不变的部分，并将可变的行为留给子类来实现
    2. 各子类中公共的行为被提取出来并集中到一个公共父类中，从而避免代码重复

**优点**

    1. 提高复用性
    2. 提高扩展性
    3. 符合开闭原则

**缺点**

    1. 类数目增加
    2. 增加了系统实现的复杂度
    3. 继承关系自身缺点，如果父类添加新的抽象方法，所有子类都要改一遍

**扩展**

    1. 钩子方法
    
**相关设计模式**

    1. 工厂方法模式
    2. 策略模式

#### UML图
![模板方法](images/模板方法.png)

### *14. 迭代器模式(iterator)

**定义**

    提供一种方法，顺序访问一个集合对象中的各个元素，而又不暴露该对象的内部表示

**类型**

    行为型

**适用场景**

    1. 访问一个集合对象的内容而无需暴露它的内部表示
    2. 为遍历不同的集合结构提供一个统一的接口

**优点**

    1. 分离了集合对象的遍历行为

**缺点**

    1. 类的个数成对增加

**相关设计模式**

    1. 访问者模式

### 15. 策略模式(strategy)

**定义**

    定义了算法家族，分别封装起来，让它们之间可以相互替换，此模式让算法的变化不会影响到使用算法的用户
    （大量 if...else... 时推荐使用）

**类型**

    行为型

**适用场景**

    1. 系统有很多类，而他们的区别仅仅在于他们的行为不同
    2. 一个系统需要动态地在几种算法中选择一种

**优点**

    1. 开闭原则
    2. 避免使用多重条件转移语句
    3. 提高算法的保密性和安全性

**缺点**

    1. 客户端必须知道所有的策略类，并自行决定使用哪一个策略类
    2. 产生很多策略类

**相关设计模式**

    1. 工厂模式
    2. 状态模式

#### UML图
![策略模式](images/策略模式.png)

### *16. 解释器模式(interpreter)

**定义**

    给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子
    为了解释一种语言，而为语言创建的解释器

**类型**

    行为型

**适用场景**

    1. 某个特定类型问题发生频率足够高

**优点**
    
    1. 语法由很多类表示，容易改变及扩展此"语言"

**缺点**

    1. 当语法规则数目太多时，增加了系统复杂度

**相关设计模式**

    1. 适配器模式
    
#### UML图
![解释器模式](images/解释器模式.png)

### *17. 观察者模式(observer)

**定义**

    定义了对象之间一对多依赖，让多个观察者对象同时监听某一个主体对象，当主体对象发生变化时，它的所有依赖者（观察者）都会收到通知并更新

**类型**

    行为型

**适用场景**

    1. 关联行为场景，建立一套触发机制

**优点**

    1. 观察者和被观察者之间建立一个抽象的耦合
    2. 观察者模式支持广播通信

**缺点**

    1. 观察者之间有过多的细节依赖、提高时间消耗及程序复杂度
    2. 使用要得当，要避免循环调用

### *18. 备忘录模式(memento)

**定义**

    保存一个对象的某个状态，以便在适当的时候恢复对象
    "后悔药"

**类型**

    行为型

**适用场景**

    1. 保存及恢复数据相关业务场景
    2. 后悔的时候，即想恢复到之前的状态

**优点**

    1. 为用户提供一种可恢复的机制
    2. 存档信息的封装

**缺点**

    1. 资源占用

**相关设计模式**

    1. 状态模式

### *19.命令模式(command)

**定义**

    将"请求"封装成对象，以便使用不同的请求
    命令模式解决了应用程序中对象的职责以及它们之间的通信方式

**类型**

    行为型

**适用场景**

    1. 请求调用者和请求接收者需要解耦，使得调用者和接收者不直接交互
    2. 需要抽象出等待执行的行为

**优点**

    1. 降低耦合
    2. 容易扩展新命令或者一组命令

**缺点**

    1. 命令的无限扩展会增加类的数量，提高系统实现的复杂度

**相关设计模式**

    1. 备忘录模式

#### UML图
![命令模式](images/命令模式.png)

### *20. 中介者模式(mediator)

**定义**

    定义一个 封装一组对象如何交互 的对象
    通过使对象明确地相互引用来促进松散耦合，并允许独立地改变它们的交互

**类型**

    行为型

**适用场景**

    1. 系统中对象之间存在复杂的引用关系，产生的相互依赖关系结构混乱且难以理解
    2. 交互的公共行为，如果需要改变行为则可以增加新的中介者类

**优点**

    1. 将一对多转化成一对一、降低程序复杂度
    2. 类之间解耦

**缺点**

    1. 中介者过多，导致系统复杂

**相关设计模式**

    1. 观察者模式

### 21. 责任链模式(chain of responsibility)

**定义**

    为请求创建一个接收此次请求的链

**类型**

    行为型

**适用场景**

    1. 一个请求的处理需要多个对象当中的一个或几个协作处理

**优点**

    1. 请求的发送者和接收者（请求的处理）解耦
    2. 责任链可以动态组合

**缺点**

    1. 责任链太长或者处理时间太长，影响性能
    2. 责任链可能过多

**相关设计模式**

    1. 状态模式

### *22. 访问者模式(visitor)

**定义**

    封装作用于某种数据结构(如List/Map/Set等)中的各元素的操作
    可以在不改变各元素的类的前提下，定义作用于这些元素的操作

**类型**

    行为型

**适用场景**

    1. 一个数据结构(如List/Map/Set等)包含很多类型对象
    2. 数据结构与数据操作分离

**优点**

    1. 增加新的操作很容易，即增加一个新的访问者

**缺点**

    1. 增加新的数据结构困难
    2. 具体元素的变更比较麻烦

**相关设计模式**

    1. 迭代器模式

### 23. 状态模式(state)

**定义**

    允许一个对象在其内部状态改变时，改变它的行为

**类型**

    行为型

**适用场景**

    1. 一个对象存在多个状态（不同状态下行为不同），且状态可相互转换

**优点**

    1. 将不同的状态隔离
    2. 把各种状态的转换逻辑，分布到State的子类中，减少相互间依赖
    3. 增加新的状态简单

**缺点**

    1. 状态多的业务场景导致类数目增加，系统变复杂

**相关设计模式**

    1. 享元模式

#### UML图
![状态模式](images/状态模式.png)