# 23 种设计模式

**Repository Path**: xxacker/design-patterns

## Basic Information

- **Project Name**: 23 种设计模式
- **Description**: 23 种设计模式学习，及其应用场景
- **Primary Language**: Java
- **License**: Apache-2.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 2
- **Forks**: 1
- **Created**: 2021-07-08
- **Last Updated**: 2022-08-30

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 23 种设计模式

#### 介绍
23种设计模式学习，及其应用场景

#### 一、创建型
创建型模式：对类的实例化过程进行了抽象，能够将软件模块中 对象的创建 和 对象的使用 分离。

1. 工厂模式
2. 抽象工厂模式
3. 单例模式
4. 建造者模式
5. 原型模式

#### 二、结构型
结构性模式：重点关注于 对象的组成 ，以及对象之间的依赖关系，描述 如何将类结合在一起 形成更大的结构，就像搭积木，可以通过简单的积木组合成复杂的、功能更更加强大的结构。

1. 适配器模式
2. 装饰者模式
3. 代理模式
4. 外观模式
5. 桥接模式
6. 组合模式
7. 享元模式

#### 三、行为型
行为型模式：关注于 对象的行为问题 ，是对在不同的对象之间 划分责任和算法的抽象化 ；不仅仅关注类和对象的结构，而且重点关注它们之间的相互作用。

1. 策略模式
2. 模板方法模式
3. 观察者模式
4. 迭代器模式
5. 责任链模式
6. 命令模式
7. 备忘录模式
8. 状态模式
9. 访问者模式
10. 中介模式
11. 解释器模式

### 四、设计原则
### 总原则 - 开闭原则
一个模块、类、方法应该对外拓展开放，对修改关闭。
对程序进行拓展的时候， 不能去改动原有的代码  ，而是 扩展原有代码 ，实现一个热插拔的效果。
所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。
实现方式：使用 接口 和 抽象类 。

#### 1、单一职责原则（Single）
一个类应该只有一个发生变化的原因
每个类应该实现单一的职责，否则应该将类进行拆分。
导致类变更的原因不能多于一个。

#### 2、接口隔离原则（Interface）
类之间的依赖关系应建立在最小的接口上
如果接口中存在子类用不到却必须实现的方法，就要将接口进行拆分。
使用多个隔离的接口，比使用单个接口（多个接口方法集合到一个的接口）要好。

#### 3、里氏替换原则（Liskov）
所有引用父类的地方都能够透明地使用其子类的对象。
基类、超类就是父类，派生类就是子类；
在父类可以出现的地方，子类一定可以出现。
替换原则就是继承复用的基石，只有当子类可以替换父类，程序中的功能还不受影响的时候，父类就被子类服用，并且子类也能够在父类的基础上增加新的函数方法。

里氏替换原则是对 “ 开-闭 ” 原则的补充，实现 “ 开-闭 ” 原则的关键是抽象化，而父类和子类的继承关系就是抽象化的具体实现。
所以里氏替换原则就是对实现抽象化步骤的规范。

在里氏替换原则中， 子类对父类的方法尽量不要重写和重载 。应为父类代表了定义好的结构，通过这个规范与外界交互，字类不应该随便破坏它。

#### 4、依赖倒置原则（Dependence）
1. 抽象不应该依赖于细节，细节应该依赖于抽象。
2. 上层模块不应该依赖于底层模块，他们应该依赖于抽象
面向接口编程，依赖于抽象而不依赖于具体。写代码时，用到具体类时，不与具体类交互，而与具体类的上层接口交互。

#### 5、迪米特法则 < 最少知道原则 >（Law）
只与你的直接盆友交谈，不跟“陌生人”说话
一个类对自己依赖的类知道的越少越好。无论被依赖的类对么复杂，都应该将逻辑封装在方法内部，通过 public 方法提供给外部。这样当被依赖的类变化是，才能最小影响到该类。

最少知道原则的另一种表达方式是：至于直接的朋友通信。类之间只要有耦合关系，就叫朋友。

#### 6、合成复用原则（Composite ）
尽量使用对象组合 / 聚合，而不是继承关系达到软件复用的目的。
组合 / 聚合可以将已有对象纳入新对象中，使之成为新对象的一部分，因此新对象可以直接调用以由对象的共功能