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。
最小常识准则
每个模块只应该理解那些与它关系密切的模块的无限常识。
不该有间接依赖关系的类之间，不要有依赖。有依赖关系的类之间，尽量只依赖必要的接口。迪米特法令是心愿缩小类之间的耦合，让类越独立越好。每个类都应该少理解零碎的其余局部。一旦发生变化，须要理解这一变动的类就会比拟少。
如何了解“高内聚、松耦合”？
所谓高内聚，就是指相近的性能应该放到同一个类中，不相近的性能不要放到同一类中。相近的性能往往会被同时批改，放到同一个类中，批改会比拟集中。
所谓松耦合指的是，在代码中，类与类之间的依赖关系简略清晰。即便两个类有依赖关系，一个类的代码改变也不会或者很少导致依赖类的代码改变。