摘录了对以上几大基本设计原则的简介，方便从定义方面对比它们。

单一职责(S)

单一职责(SRP,Single Responsibility)，一个类或者模块只负责完成一个职责或者功能。一个类只负责完成一个职责或者功能。

从类的角度来讲，一个类只负责完成一个职责或者功能。也就是说，不要设计大而全的类，要设计粒度小、功能单一的类。换个角度来讲就是，一个类包含了两个或者两个以上业务不相干的功能，那我们就说它职责不够单一，应该将它拆分成多个功能更加单一、粒度更细的类。

不同的应用场景、不同阶段的需求背景、不同的业务层面，对同一个类的职责是否单一，可能会有不同的判定结果。实际上，一些侧面的判断指标更具有指导意义和可执行性，比如，出现下面这些情况就有可能说明这类的设计不满足单一职责原则:

• 类中的代码行数、函数或者属性过多;
• 类依赖的其他类过多，或者依赖类的其他类过多;·私有方法过多;
• 比较难给类起一个合适的名字;
• 类中大量的方法都是集中操作类中的某几个属性。

单一职责原则通过避免设计大而全的类，避免将不相关的功能耦合在一起，来提高类的内聚性。同时，类职责单一，类依赖的和被依赖的其他类也会变少，减少了代码的耦合性，以此来实现代码的高内聚、低耦合。但是，如果拆分得过细，实际上会适得其反，反倒会降低内聚性，也会影响代码的可维护性。

开闭原则(O)

开闭原则的英文全称是Open Closed Principle，简写为OCP。它的英文描述是: softwareentities (modules, classes, functions, etc.) should be open for extension , but closed for modification。我们把它翻译成中文就是:软件实体（模块、类、方法等）应该“对扩展开放、对修改关闭”。这个描述比较简略，如果我们详细表述一下，那就是，添加一个新的功能应该是，在已有代码基础上扩展代码（新增模块、类、方法等），而非修改已有代码（修改模块、类、方法等)。

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

我们要时刻具备扩展意识、抽象意识、封装意识。在写代码的时候，我们要多花点时间思考一下，这段代码未来可能有哪些需求变更，如何设计代码结构，事先留好扩展点，以便在未来需求变更的时候，在不改动代码整体结构、做到最小代码改动的情况下，将新的代码灵活地插入到扩展点上。
很多设计原则、设计思想、设计模式，都是以提高代码的扩展性为最终目的的。特别是23种经典设计模式，大部分都是为了解决代码的扩展性问题而总结出来的，都是以开闭原则为指导原则的。最常用来提高代码扩展性的方法有:多态、依赖注入、基于接口而非实现编程，以及大部分的设计模式（比如，装饰、策略、模板、职责链、状态）。

里氏替换原则(L)

里式替换原则的英文翻译是: Liskov Substitution Principle，缩写为LSP。这个原则最早是在1986年由Barbara Liskov提出，他是这么描述这条原则的:lf S is a subtype of T, then objects of type T may be replaced with objects of type S,without breaking the program。
在1996年，Robert Martin在他的SOLID原则中，重新描述了这个原则，英文原话是这样的:Functions that use pointers of references to base classes must be able to useobjects of derived classes without knowing it。
我们综合两者的描述，将这条原则用中文描述出来，是这样的:子类对象（object of subtype/derived class）能够替换程序(program)中父类对象（(object of base/parentclass）出现的任何地方，并且保证原来程序的逻辑行为(behavior)不变及正确性不被破坏。

实际上，里式替换原则还有另外一个更加能落地、更有指导意义的描述，那就是“Design ByContract”，中文翻译就是“按照协议来设计”。
看起来比较抽象，我来进一步解读一下。子类在设计的时候，要遵守父类的行为约定(或者叫协议）。父类定义了函数的行为约定，那子类可以改变函数的内部实现逻辑，但不能改变函数原有的行为约定。这里的行为约定包括:函数声明要实现的功能;对输入、输出、异常的约定;甚至包括注释中所罗列的任何特殊说明。实际上，定义中父类和子类之间的关系，也可以替换成接口和实现类之间的关系。
理解这个原则，我们还要弄明白里式替换原则跟多态的区别。虽然从定义描述和代码实现上来看，多态和里式替换有点类似，但它们关注的角度是不一样的。多态是面向对象编程的一大特性，也是面向对象编程语言的一种语法。它是一种代码实现的思路。而里式替换是一种设计原则，用来指导继承关系中子类该如何设计，子类的设计要保证在替换父类的时候，不改变原有程序的逻辑及不破坏原有程序的正确性。

接口隔离原则(I)

接口隔离原则的英文翻译是“ Interface Segregation Principle”，缩写为ISP。RobertMartin在SOLID原则中是这样定义它的: “Clients should not be forced to dependupon interfaces that they do not use。”直译成中文的话就是:客户端不应该强迫依赖它不需要的接口。其中的“客户端”，可以理解为接口的调用者或者使用者。
实际上，“接口”这个名词可以用在很多场合中。生活中我们可以用它来指插座接口等。在软件开发中，我们既可以把它看作一组抽象的约定，也可以具体指系统与系统之间的API接口，还可以特指面向对象编程语言中的接口等。
前面我提到，理解接口隔离原则的关键，就是理解其中的“接口”二字。在这条原则中，我们可以把“接口”理解为下面三种东西:

• 一组API接口集合
• 单个API接口或函数
• OOP中的接口概念

如果把“接口”理解为一组接口集合，可以是某个微服务的接口，也可以是某个类库的接口等。如果部分接口只被部分调用者使用，我们就需要将这部分接口隔离出来，单独给这部分调用者使用，而不强迫其他调用者也依赖这部分不会被用到的接口。

如果把“接口”理解为单个API接口或函数，部分调用者只需要函数中的部分功能,那我们就需要把函数拆分成粒度更细的多个函数，让调用者只依赖它需要的那个细粒度函数。

如果把“接口”理解为OOP中的接口，也可以理解为面向对象编程语言中的接口语法。那接口的设计要尽量单一，不要让接口的实现类和调用者，依赖不需要的接口函数。
单一职责原则针对的是模块、类、接口的设计。接口隔离原则相对于单一职责原则，一方面更侧重于接口的设计，另一方面它的思考角度也是不同的。接口隔离原则提供了一种判断接口的职责是否单一的标准:通过调用者如何使用接口来间接地判定。如果调用者只使用部分接口或接口的部分功能，那接口的设计就不够职责单一。

依赖反转(D)

控制反转

实际上，控制反转是一个比较笼统的设计思想，并不是一种具体的实现方法，一般用来指导框架层面的设计。这里所说的“控制”指的是对程序执行流程的控制，而“反转”指的是在没有使用框架之前，程序员自己控制整个程序的执行。在使用框架之后，整个程序的执行流程通过框架来控制。流程的控制权从程序员“反转”给了框架。

依赖注入

依赖注入和控制反转恰恰相反，它是一种具体的编码技巧。我们不通过new的方式在类内部创建依赖类的对象，而是将依赖的类对象在外部创建好之后，通过构造函数、函数参数等方式传递(或注入）给类来使用。

依赖注入框架

我们通过依赖注入框架提供的扩展点，简单配置一下所有需要的类及其类与类之间依赖关系，就可以实现由框架来自动创建对象、管理对象的生命周期、依赖注入等原本需要程序员来做的事情。

依赖反转原则

依赖反转原则的英文翻译是Dependency lnversion Principle，缩写为DIP。中文翻译有时候也叫依赖倒置原则。
为了追本溯源，我先给出这条原则最原汁原味的英文描述:High-level modules shouldn’t depend on low-level modules.Both modules shoulddepend on abstractions. In addition, abstractions shouldn’t depend on details.

我们将它翻译成中文，大概意思就是:高层模块(high-level modules）不要依赖低层模块(low-level)。高层模块和低层模块应该通过抽象(abstractions)来互相依赖。除此之外，抽象(abstractions）不要依赖具体实现细节(details)，具体实现细节(details）依赖抽象(abstractions)。

所谓高层模块和低层模块的划分，简单来说就是，在调用链上，调用者属于高层，被调用者属于低层。在平时的业务代码开发中，高层模块依赖底层模块是没有任何问题的。实际上，这条原则主要还是用来指导框架层面的设计，跟前面讲到的控制反转类似。我们拿Tomcat这个Servlet容器作为例子来解释一下。

Tomcat是运行Java Web应用程序的容器。我们编写的Web应用程序代码只需要部署在Tomcat容器下，便可以被Tomcat容器调用执行。按照之前的划分原则，Tomcat就是高层模块，我们编写的 Web应用程序代码就是低层模块。Tomcat和应用程序代码之间并没有直接的依赖关系，两者都依赖同一个“抽象”，也就是Sevlet规范。Servlet规范不依赖具体的Tomcat容器和应用程序的实现细节，而Tomcat容器和应用程序依赖Servlet 规范.

KISS(Keep It Simple and Stupid)

KISS, Keep It Simple and Stupid.翻译成中文就是尽量保持简单。KISS原则是保持代码可读和可维护的重要手段。KISS原则中的“简单”并不是以代码行数来考量的。代码行数越少并不代表代码越简单，我们还要考虑逻辑复杂度、实现难度、代码的可读性等。而且，本身就复杂的问题，用复杂的方法解决，并不违背KISS原则。除此之外，同样的代码，在某个业务场景下满足KISS 原则，换一个应用场景可能就不满足了。
对于如何写出满足KISS )原则的代码，我还总结了下面几条指导原则:

• 不要使用同事可能不懂的技术来实现代码;
• 不要重复造轮子，要善于使用已经有的工具类库;
• 不要过度优化。

YAGNI

YAGNI原则的英文全称是: You Ain’ t Gonna Need lt。直译就是:你不会需要它。
这条原则也算是万金油了。当用在软件开发中的时候，它的意思是:不要去设计当前用不到的功能;不要去编写当前用不到的代码。实际上，这条原则的核心思想就是:不要做过度设计比如，我们的系统暂时只用Redis存储配置信息，以后可能会用到ZooKeeper。根据YAGNI原则，在未用到ZooKeeper之前，我们没必要提前编写这部分代码。当然，这并不是说我们就不需要考虑代码的扩展性。我们还是要预留好扩展点，等到需要的时候，再去实现ZooKeeper存储配置信息这部分代码。再比如，我们不要在项目中提前引入不需要依赖的开发包。对于Java程序员来说，我们经常使用Maven或者Gradle来管理依赖的类库(library)。我发现，有些同事为了避免开发中library包缺失而频繁地修改Maven或者Gradle配置文件，提前往项目里引入大量常用的library包。实际上，这样的做法也是违背YAGNI)原则的。从刚刚的分析我们可以看出，YAGNI原则跟KISS原则并非一回事儿。KISS原则讲的是“如何做”的问题(尽量保持简单)，而YAGNI原则说的是“要不要做”的问题(当前不需要的就不要做)。

DRY原则(Don't Repeat Yourself)

DRY 原则的定义非常简单，我就不再过度解读。今天，我们主要讲三种典型的代码重复情况，它们分别是:实现逻辑重复、功能语义重复和代码执行重复。这三种代码重复，有的看似违反DRY，实际上并不违反;有的看似不违反，实际上却违反了。实现逻辑重复，但功能语义不重复的代码，并不违反DRY 原则。实现逻辑不重复，但功能语义重复的代码，也算是违反DRY原则。除此之外，代码执行重复也算是违反DRY原则。

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

• 减少代码耦合
• 满足单一职责原则
• 模块化
• 业务与非业务逻辑分离
• 通用代码下沉
• 继承、多态、抽象、封装
• 应用模板等设计模式

LOD(最小知识原则)

迪米特法则的英文翻译是: Law of Demeter，缩写是LOD。单从这个名字上来看，我们完全猜不出这个原则讲的是什么。不过，它还有另外一个更加达意的名字，叫作最小知识原则，英文翻译为: The Least Knowledge Principle。关于这个设计原则，我们先来看一下它最原汁原味的英文定义:Each unit should have only limited knowledge about other units: only units“closely”related to the current unit. Or: Each unit should only talk to its friends;Don’t talk to strangers.
我们把它直译成中文，就是下面这个样子:每个模块(unit）只应该了解那些与它关系密切的模块(units: only units "closely"related to the current unit)的有限知识(knowledge)。或者说，每个模块只和自己的朋友“说话”(talk)，不和陌生人“说话”(talk)。

我们之前讲过，大部分设计原则和思想都非常抽象，有各种各样的解读，要想灵活地应用到实际的开发中，需要有实战经验的积累。迪米特法则也不例外。所以，我结合我自己的理解和经验，对刚刚的定义重新描述一下。注意，为了统一讲解，我把定义描述中的“模块”替换成了“类”。

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

“高内聚、松耦合”是一个非常重要的设计思想，能够有效提高代码的可读性和可维护性，缩小功能改动导致的代码改动范围。“高内聚”用来指导类本身的设计，“松耦合”用来指导类与类之间依赖关系的设计。
所谓高内聚，就是指相近的功能应该放到同一个类中，不相近的功能不要放到同一类中。相近的功能往往会被同时修改，放到同一个类中，修改会比较集中。所谓松耦合指的是，在代码中，类与类之间的依赖关系简单清晰。即使两个类有依赖关系，一个类的代码改动也不会或者很少导致依赖类的代码改动。