SOLID原则是由五个设计原则组成：单一职责原则（SRP），开闭原则（OCP），里式替换原则（LSP），接口隔离原则（ISP），依赖反转原则（DIP）

单一职责原则（SRP）

概念

单一职责原则的英文是 Single Responsibility Principle，缩写为 SRP。

一个类只负责完成一个职责或者功能。不要设计大而全的类，要设计粒度小、功能单一的类。单一职责原则是为了实现代码高内聚、低耦合，提高代码的复用性、可读性、可维护性。

如何判断类的职责是否足够单一？

不同的应用场景、不同阶段的需求背景、不同的业务层面，对同一个类的职责是否单一，可能会有不同的判定结果。

一些侧面的判断指标更具有指导意义和可执行性，比如，出现下面这些情况就有可能说明这类的设计不满足单一职责原则：

• 类中的代码行数、函数或者属性过多；

• 类依赖的其他类过多，或者依赖类的其他类过多；

• 私有方法过多；

• 比较难给类起一个合适的名字；

• 类中大量的方法都是集中操作类中的某几个属性。

类的职责是否设计得越单一越好？

单一职责原则是为了实现代码高内聚、低耦合，如果拆分得过细，实际上会适得其反，反倒会降低内聚性，也会影响代码的可维护性。

开闭原则（OCP）

概念

开闭原则的英文全称是 Open Closed Principle，简写为 OCP。

软件实体（模块、类、方法等）应该“对扩展开放、对修改关闭”。

添加一个新的功能，应该是通过在已有代码基础上扩展代码（新增模块、类、方法、属性等），而非修改已有代码（修改模块、类、方法、属性等）的方式来完成。关于定义，我们有两点要注意。第一点是，开闭原则并不是说完全杜绝修改，而是以最小的修改代码的代价来完成新功能的开发。第二点是，同样的代码改动，在粗代码粒度下，可能被认定为“修改”；在细代码粒度下，可能又被认定为“扩展”。

如何做到“对扩展开放、修改关闭”？

我们要时刻具备扩展意识、抽象意识、封装意识，在写代码的时候，多思考这段代码未来可能有哪些需求变更，如何设计代码结构，事先留好扩展点，以便将新的代码灵活地插入到扩展点上。

23 种经典设计模式，大部分都是为了解决代码的扩展性问题而总结出来的，都是以开闭原则为指导原则的。最常用来提高代码扩展性的方法有：多态、依赖注入、基于接口而非实现编程，以及大部分的设计模式（比如，装饰、策略、模板、职责链、状态）。

里式替换原则（LSP）

概念

里式替换原则的英文翻译是：Liskov Substitution Principle，缩写为 LSP。

子类对象能够替换程序中父类对象出现的任何地方，并且保证原来程序的逻辑行为不变及正确性不被破坏。

里式替换原则是用来指导，继承关系中子类该如何设计的一个原则。理解里式替换原则，最核心的就是理解“design by contract，按照协议来设计”这几个字。父类定义了函数的“约定”（或者叫协议），那子类可以改变函数的内部实现逻辑，但不能改变函数原有的“约定”。这里的约定包括：函数声明要实现的功能；对输入、输出、异常的约定；甚至包括注释中所罗列的任何特殊说明。

里式替换原则跟多态的区别

虽然从定义描述和代码实现上来看，多态和里式替换有点类似，但它们关注的角度是不一样的。多态是面向对象编程的一大特性，也是面向对象编程语言的一种语法。它是一种代码实现的思路。而里式替换是一种设计原则，用来指导继承关系中子类该如何设计，子类的设计要保证在替换父类的时候，不改变原有程序的逻辑及不破坏原有程序的正确性。

接口隔离原则（ISP）

概念

接口隔离原则的英文翻译是“ Interface Segregation Principle”，缩写为 ISP。

客户端不应该强迫依赖它不需要的接口。其中的“客户端”，可以理解为接口的调用者或者使用者。

接口的设计要尽量单一，不要让接口的实现类和调用者，依赖不需要的接口函数。

接口隔离原则与单一职责原则的区别

单一职责原则针对的是模块、类、接口的设计。接口隔离原则相对于单一职责原则，一方面更侧重于接口的设计，另一方面它的思考角度也是不同的。接口隔离原则提供了一种判断接口的职责是否单一的标准：通过调用者如何使用接口来间接地判定。如果调用者只使用部分接口或接口的部分功能，那接口的设计就不够职责单一。

依赖反转原则（DIP）

概念

依赖反转原则。依赖反转原则的英文翻译是 Dependency Inversion Principle，缩写为 DIP。

高层模块不要依赖低层模块。高层模块和低层模块应该通过抽象来互相依赖。除此之外，抽象不要依赖具体实现细节，具体实现细节依赖抽象。

所谓高层模块和低层模块的划分，简单来说就是，在调用链上，调用者属于高层，被调用者属于低层。

控制反转（IOC）

这里的“控制”指的是对程序执行流程的控制，而“反转”指的是在没有使用框架之前，程序员自己控制整个程序的执行。在使用框架之后，整个程序的执行流程可以通过框架来控制。流程的控制权从程序员“反转”到了框架。

实现控制反转的方法有很多，控制反转并不是一种具体的实现技巧，而是一个比较笼统的设计思想，一般用来指导框架层面的设计。

依赖注入（DI）

什么是依赖注入呢？我们用一句话来概括就是：不通过 new() 的方式在类内部创建依赖类对象，而是将依赖的类对象在外部创建好之后，通过构造函数、函数参数等方式传递（或注入）给类使用。

KISS 原则

概念

KISS 原则。英文是 Keep It Simple and Stupid，缩写为 KISS。

尽量保持简单

KISS 原则中的“简单”并不是以代码行数来考量的。代码行数越少并不代表代码越简单，我们还要考虑逻辑复杂度、实现难度、代码的可读性等。而且，本身就复杂的问题，用复杂的方法解决，并不违背 KISS 原则。除此之外，同样的代码，在某个业务场景下满足 KISS 原则，换一个应用场景可能就不满足了。

对于如何写出满足 KISS 原则的代码

• 不要使用同事可能不懂的技术来实现代码；

• 不要重复造轮子，要善于使用已经有的工具类库；

• 不要过度优化。

DRY 原则

概念

DRY 原则为Don’t Repeat Yourself

不要重复造轮子

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

提高代码可复用性的一些方法

• 减少代码耦合

• 满足单一职责原则

• 模块化

• 业务与非业务逻辑分离

• 通用代码下沉

• 继承、多态、抽象、封装

• 应用模板等设计模式

我们在第一次写代码的时候，如果当下没有复用的需求，而未来的复用需求也不是特别明确，并且开发可复用代码的成本比较高，那我们就不需要考虑代码的复用性。在之后开发新的功能的时候，发现可以复用之前写的这段代码，那我们就重构这段代码，让其变得更加可复用。

相比于代码的可复用性，DRY 原则适用性更强一些。我们可以不写可复用的代码，但一定不能写重复的代码。

迪米特法则（LOD）

概念

迪米特法则的英文翻译是：Law of Demeter，缩写是 LOD。它还有另外一个更加达意的英文翻译为：The Least Knowledge Principle。

最小知识原则

每个模块只应该了解那些与它关系密切的模块的有限知识。

不该有直接依赖关系的类之间，不要有依赖。有依赖关系的类之间，尽量只依赖必要的接口。迪米特法则是希望减少类之间的耦合，让类越独立越好。每个类都应该少了解系统的其他部分。一旦发生变化，需要了解这一变化的类就会比较少。

如何理解“高内聚、松耦合”？

所谓高内聚，就是指相近的功能应该放到同一个类中，不相近的功能不要放到同一类中。相近的功能往往会被同时修改，放到同一个类中，修改会比较集中。

所谓松耦合指的是，在代码中，类与类之间的依赖关系简单清晰。即使两个类有依赖关系，一个类的代码改动也不会或者很少导致依赖类的代码改动。