| 设计原则 | 英文表达 | 说明 |
| 单一职责原则 | SRP，Single Responsibility Principle | 一个类，应该仅有一个引起你它变化的原因。不要讲变化原因不同的职责封装在一起，而应该分离。 |
| 开放封闭原则 | OCP，Open Closed Principle | 软件实体应当对修改关闭，对扩展放开。 |
| 依赖倒置原则 | DIR，Dependency Inversion Principle | 依赖于抽象，而不应该依赖于具体，因为抽象相对稳定。 |
| 接口隔离原则 | ISP，Interface Inversion Principle | 尽量应用专门的接口，而不是单一的总接口，接口应该面向用户，将依赖建立在最小的接口上。 |
| Liskov替换原则 | LSP，Liskov Substitution Principle | 子类必须能够替换基其基类。 |
单一职责原则
核心思想：一个类，最好只做一件事，只有一个引起它变化的原因。
单一职责原则可以看做是低耦合高内聚在面向对象原则上的引申，将职责定义为引起变化的原因，以提高内聚性来减少变化的原因。
遵循这条规则的关键，并不是从功能点的多少来划分，而是从引起类变化的原因来把握。
可以通过Facade模式或Proxy模式进行职责分离。
开放封闭原则
核心思想：软件实体应该是可扩展，而不可修改的。也就是说对其扩展是开放的，对其修改是封闭的。
主要体现在两个方面：
对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的需求。
对修改封闭，意味着类一旦设计完成，就可以独立完成其工作，而不要对类进行任何修改。
实现开放封闭的核心思想就是对抽象编程，而不是对具体编程，因为对抽象编程来说相对于稳定。
常用于实现的模式主要有Template Method模式和Strategy模式。
依赖倒置原则
核心思想：依赖于抽象
主要体现在：
高层模块不应该依赖于底层模块，二者都应该依赖于抽象。
抽象不应该依赖于具体，具体应该依赖于抽象。
依赖，一定会存在于类鱼类、模块与模块之间：依赖关系，也一定是系统设计必须关注的要点。面向对象设计在魔种层次上，就是一个关于关系处理的哲学，而依赖倒置原则正式这种哲学思想在具体应用中的体现。当两个模块之间存在紧耦合的关系时，最好的办法就是分离接口和实现：在依赖之间定义一个抽象的接口，使得高层模块调用接口的方法，而底层模块实现接口的定义，一次来有效控制耦合关系，达到依赖于抽象的设计目标。
抽象的稳定决定系统的稳定性，因为抽象是保持不变的，依赖于抽象是面向对象设计的精髓，也是依赖倒置原则的核心思想。
依赖于抽象是一个通用的规则，而某些时候依赖于细节是在所难免的。必须权衡在首相和具体之间的取舍，方法不是一成不变的。
依赖于抽象，就是要对接口编程，不要对实现编程。
接口隔离原则
核心思想：使用多个小的专门接口，而不要使用一个大的接口。
主要体现在：
接口应该是内聚的，应该避免出现“胖”的接口。
一个类对另一个类的依赖应该建立在最小的接口上，不要强迫依赖不用的方法，这是一种接口污染。
分离手段主要有两种：
委托分离，通过增加一个新的类型来委托客户的请求，隔离客户和接口的直接依赖，但是会增加系统开销。
多重继承分离，通过接口多继承来实现客户的需求，这种方式值得推荐。
对于接口的理解并不完全局限于程序语义上定义的接口概念，还代表了逻辑上的接口概念。程序语言上的接口，就像C#语言中的interface定义的数据类型接口，接口隔离要求interface仅提供客户需要的程序特征；而逻辑接上的接口，代表了方法特征的集合，也可能是一个新的类型。不管怎样，为每个客户实现特定的接口，是接口隔离原则的统一思想。
建议规则：
将功能相似的接口合并，可能造成接口污染，实现内聚的接口才是接口设计的基本原则。
接口隔离原则，能够宝成系统扩展和修改的影响不会扩展到系统的其他部分，一定程度上对开放粉笔原则的遵守。