设计模式-法则大全

SOLID原则：

• 单一职责原则SRP：一个类只负责完成一个职责或功能；要设计粒度小、功能单一的类
• 开闭原则OCP：对扩展开放、对修改关闭；在已有基础上扩展代码（新增模块、类、方法等），而非修改已有代码（修改模块、类、方法等）；
• 里式替换LSP：父类定义了函数的“约定”（或者协议），那子类可以改变函数的内部实现逻辑，但不能改变函数原有的“约定”。和多态进行关联区分
• 接口隔离ISP：让调用者只依赖它需要的接口

// 如果把“接口”理解为一组接口集合，可以是某个微服务的接口，也可以是某个类库的接口等。如果部分接口只被部分调用者使用，我们就需要将这部分接口隔离出来，单独给这部分调用者使用，而不强迫其他调用者也依赖这部分不会被用到的接口。
// 如果把“接口”理解为单个 API 接口或函数，部分调用者只需要函数中的部分功能，那我们就需要把函数拆分成粒度更细的多个函数，让调用者只依赖它需要的那个细粒度函数。
// 如果把“接口”理解为 OOP 中的接口，也可以理解为面向对象编程语言中的接口语法。那接口的设计要尽量单一，不要让接口的实现类和调用者，依赖不需要的接口函数。

• 依赖注入DI：不通过 new 的方式在类内部创建依赖类的对象，而是将依赖的类对象在外部创建好之后，通过构造函数、函数参数等方式传递（或注入）给类来使用。

KISS原则：Keep It Simple and Stupid--“如何做”的问题（尽量保持简单）

YANGI原则：You Ain’t Gonna Need It--“要不要做”的问题（当前不需要的就不要做）

DRY原则：Don’t Repeat Yourself--懂得界定：实现逻辑重复、功能语义重复、代码执行重复

// 实现逻辑重复，但功能语义不重复的代码，并不违反 DRY 原则。
// 实现逻辑不重复，但功能语义重复的代码，也算是违反 DRY 原则。
// 代码执行重复也算是违反 DRY 原则。

迪米特法则LOD：The Least Knowledge Principle--最小知识原则

// 不该有直接依赖关系的类之间，不要有依赖；
// 有依赖关系的类之间，尽量只依赖必要的接口（也就是定义中的“有限知识”）。