设计模式总览

9条设计原则

• SOLID
  • SRP 单一职责原则：个类或者模块只负责完成一个职责
  • OCP 开闭原则：软件实体（模块、类、方法等）应该“对扩展开放、对修改关闭”。添加一个新的功能应该是，在已有代码基础上扩展代码（新增模块、类、方法等），而非修改已有代码（修改模块、类、方法等）。
  • LSP 里式替换原则：是用来指导继承关系中子类该如何设计的，子类的设计要保证在替换父类的时候，不改变原有程序的逻辑以及不破坏原有程序的正确性。
  • ISP 接口隔离原则：客户端不应该被强迫依赖它不需要的接口
  • DIP 依赖倒置原则：高层模块（high-level modules）不要依赖低层模块（low-level）
• DRY 原则：不要写重复的代码。
• KISS 原则：尽量保持简单。
• YAGNI 原则：不要做过度设计
• LOD 法则：不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口（也就是定义中的“有限知识”）

23种经典设计模式

1.创建型

• 常用：
  • 单例模式：解决资源冲突（多线程）；全局唯一实例；
  • 工厂模式：解决创建对象时，需要组合多个其他类对象，做各种初始化操作时的复杂场景；Spring IOC
  • 建造者模式：对象初始化需要一次性初始化好所以的成员变量
• 不常用：
  • 原型模式：对象的创建成本大，而一个类的不同对象之间差别不大，可以进行复制拷贝节省创建时间

2.结构型

• 常用：
  • 代理模式：用于避免非业务逻辑对核心代码的侵入：Spring AOP
  • 桥接模式：一个类存在两个（或多个）独立变化的维度，我们通过组合的方式，让这两个（或多个）维度可以独立进行扩展
  • 装饰者模式：装饰器模式主要解决继承关系过于复杂的问题，通过组合来替代继承。它主要的作用是给原始类添加增强功能
  • 适配器模式：一般来说，适配器模式可以看作一种“补偿模式”，用来补救设计上的缺陷
• 不常用：
  • 门面模式：门面模式为子系统提供一组统一的接口，定义一组高层接口让子系统更易用。
  • 组合模式：将一组对象组织成树形结构，将单个对象和组合对象都看做树中的节点，以统一处理逻辑，并且它利用树形结构的特点，递归地处理每个子树，依次简化代码实现
  • 享元模式：如果这些重复的对象是不可变对象，我们就可以利用享元模式将对象设计成享元，在内存中只保留一份实例，供多处代码引用；Java String Integer

3.行为型

• 常用：
  • 观察者模式（发布订阅）：行为型模式是将不同的行为代码解耦，具体到观察者模式，它将观察者和被观察者代码解耦；Kafka
  • 模板模式：模板方法模式在一个方法中定义一个算法骨架，并将某些步骤推迟到子类中实现。模板方法模式可以让子类在不改变算法整体结构的情况下，重新定义算法中的某些步骤；Java Thread
  • 策略模式：利用它来避免冗长的 if-else 或 switch 分支判断
  • 职责链模式：将请求的发送和接收解耦，让多个接收对象都有机会处理这个请求。将这些接收对象串成一条链，并沿着这条链传递这个请求，直到链上的某个接收对象能够处理它为止：Spring Web Filter
  • 迭代器模式：迭代器模式将集合对象的遍历操作从集合类中拆分出来，放到迭代器类中，让两者的职责更加单一；Java容器遍历
  • 状态模式：一般用来实现状态机，而状态机常用在游戏、工作流引擎等系统开发中
• 不常用：
  • 访问者模式：访问者模式允许一个或者多个操作应用到一组对象上，设计意图是解耦操作和对象本身，保持类职责单一、满足开闭原则以及应对代码的复杂性。
  • 备忘录模式：在不违背封装原则的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，以便之后恢复对象为先前的状态。
  • 命令模式：命令模式将请求（命令）封装为一个对象，这样可以使用不同的请求参数化其他对象（将不同请求依赖注入到其他对象），并且能够支持请求（命令）的排队执行、记录日志、撤销等（附加控制）功能。
  • 解释器模式：解释器模式为某个语言定义它的语法（或者叫文法）表示，并定义一个解释器用来处理这个语法。
  • 中介模式：中介模式定义了一个单独的（中介）对象，来封装一组对象之间的交互。将这组对象之间的交互委派给与中介对象交互，来避免对象之间的直接交互。