1. SOLID原则

缩写	英文名称	中文名称
SRP	Single Responsibility Principle	单一职责原则
OCP	Open Close Principle	开闭原则
LSP	Liskov Substitution Principle	里氏替换原则
ISP	Interface Segregation Principle	接口分离原则
DIP	Dependency Inversion Principle	依赖倒置原则

ps：通常所说的SOLID不包含LoD（迪米特法则（最少知道原则））
LoD: Law of Demeter （ Least Knowledge Principle）迪米特法则（最少知道原则）

1.1 单一职责原则(SRP)，Single Responsibility Principle

这个原则的英文描述是这样的：A class or module should have a single responsibility。
一个类或者模块只负责完成一个职责（或者功能）。

1.2 开闭原则(OCP)，Open Closed Principle

它的英文描述是：software entities (modules, classes, functions, etc.) should be open for extension , but closed for modification。
软件实体（模块、类、方法等）应该“对扩展开放、对修改关闭”。
即：添加一个新的功能应该是，在已有代码基础上扩展代码（新增模块、类、方法等），而非修改已有代码（修改模块、类、方法等）。

1.3 里氏替换原则(LSP)，Liskov Substitution Principle

这个原则最早是在 1986 年由 Barbara Liskov 提出，他是这么描述这条原则的：

If 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 use objects of derived classes without knowing it。

我们综合两者的描述，将这条原则用中文描述出来，是这样的：子类对象（object of subtype/derived class）能够替换程序（program）中父类对象（object of base/parent class）出现的任何地方，并且保证原来程序的逻辑行为（behavior）不变及正确性不被破坏。
虽然从定义描述和代码实现上来看，多态和里式替换有点类似，但它们关注的角度是不一样的。多态是面向对象编程的一大特性，也是面向对象编程语言的一种语法。它是一种代码实现的思路。而里式替换是一种设计原则，是用来指导继承关系中子类该如何设计的，子类的设计要保证在替换父类的时候，不改变原有程序的逻辑以及不破坏原有程序的正确性。
里式替换原则是用来指导继承关系中子类该如何设计的一个原则。 理解里式替换原则，最核心的就是理解“design by contract（按照协议来设计）”这几个字。父类定义了函数的“约定”（或者叫协议），那子类可以改变函数的内部实现逻辑，但不能改变函数原有的“约定”。这里的约定包括：函数声明要实现的功能；对输入、输出、异常的约定；甚至包括注释中所罗列的任何特殊说明。

1.4 接口隔离原则(ISP)，Interface Segregation Principle

Clients should not be forced to depend upon interfaces that they do not use.
客户端不应该被强迫依赖它不需要的接口。其中的“客户端”，可以理解为接口的调用者或者使用者。

1.5 依赖倒置原则/依赖反转原则(DIP)，Dependency Inversion Principle

High-level modules shouldn’t depend on low-level modules. Both modules should depend on abstractions. In addition, abstractions shouldn’t depend on details. Details depend on abstractions.

高层模块（high-level modules）不要依赖低层模块（low-level）。高层模块和低层模块应该通过抽象（abstractions）来互相依赖。除此之外，抽象（abstractions）不要依赖具体实现细节（details），具体实现细节（details）依赖抽象（abstractions）。

其他原则： KISS， YANGI， DRY，迪米特法则

2. KISS原则

有三种描述方式

Keep It Simple and Stupid.
Keep It Short and Simple.
Keep It Simple and Straightforward.

翻译成中文就是：尽量保持简单。

3. YANGI原则

英文全称是：You Ain’t Gonna Need It。直译就是：你不会需要它。
实际上，这条原则的核心思想就是：不要做过度设计。

YAGNI 原则跟 KISS 原则并非一回事儿：
KISS 原则讲的是“如何做”的问题（尽量保持简单），而 YAGNI 原则说的是“要不要做”的问题（当前不需要的就不要做）。

4. DRY 原则

它的英文描述为：Don’t Repeat Yourself。中文直译为：不要重复自己。
将它应用在编程中，可以理解为：不要写重复的代码。

5. 迪米特法则（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）。

利用这个原则，能够帮我们实现代码的“高内聚、松耦合”。

参考:
《极客时间》面向对象设计的六大设计原则
 《极客时间》设计模式：面向对象设计的六大原则
 《极客时间》面向对象设计的六大设计原则
 《极客时间》里式替换（LSP）
《极客时间》我为何说KISS、YAGNI原则看似简单，却经常被用错？
《极客时间》重复的代码就一定违背DRY吗？如何提高代码的复用性？
《极客时间》如何用迪米特法则（LOD）实现“高内聚、松耦合”？