单一职责原则
· 一个类或者模块只负责完成一个职责或者功能。也就是说在类的设计中，我们不要设计大而全的类，而是要设计粒度小、功能单一的类。可以通过几个点来分析类的职责是否单一：
1. 类中的代码行数、属性或方法是否过多；
2. 类依赖的其他类是否过多；
3. 类中的私有方法是否过多；
4. 类中的大量方法是否只是频繁操作其中的某几个属性。
单一职责的判断条件在不同业务或背景下会有所不同，举个例子，User类中包含了省市县相关的字段。如果该类的定位只是用于展示用户信息则没有违反单一职责原则，但如果该类的使用范围与电商相关，则应该抽出地址相关的字段单独成类。
开发封闭原则
软件中的对象、类、方法和模块对扩展应该是开放的，但是对于修改是封闭的。简单说就是应该用抽象去定义结构，用具体实现扩展细节，以保证软件系统开发和维护过程的可靠性。符合开闭原则的设计具有如下几个优点：
1. 新老逻辑解耦，需求发生改变不会影响老业务的逻辑；
2. 改动成本最小，只需要追加新逻辑不需要改旧逻辑；
3. 为代码提供了稳定性和可扩展性；
里氏替换原则
如果S是T的子类型，对于S类型的任意对象，如果将他们看作是T类型的对象，则对象的行为也应该和期望行为一致。理解里氏替换原则首先需要搞懂两个问题：
1. 什么是替换：同一个行为具有多个不同的表现形式。简单理解就是当一个方法的参数是了个接口或基类时，这个方法可以接收所有实现过这个接口或继承了该基类的实现类；
2. 什么是与期望行为一致的替换：在不了解派生类的情况下，仅通过接口或基类的方法，就能清楚的知道方法的行为。不管哪个派生类的实现，都与接口或基类方法的期望行为一致。
接口分离原则
一个类对另一个类的依赖应该建立在最小的接口上。简单说就是要为各个类建立它们需要的专用接口，而不要试图去建立一个庞大的接口供所有依赖它的类去调用。遵循接口隔离原则具备的优势：
1. 将胖接口分解成多个粒度小的接口，可以提高系统的灵活性和可维护性；
2. 使用多个专门的接口可以提现出对象的层次；
3. 遵循接口隔离原则可以减少项目中的冗余代码。
依赖倒置原则
在设计代码架构时，高层模块不应该依赖于底层模块，两者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。可以简单理解为：由于细节具有多变性而抽象层则相对稳定。因此以抽象为基础搭建起来的架构要比以细节为基础搭建起来的架构要稳定的多。
迪米特法则
一个类、模块对其他的类、模块了解的越少越好。简单理解就是：不该有直接依赖关系的类之间不要有依赖，有依赖关系的类之间尽量只依赖必要的接口。
如果两个实体间无需直接通信，那么就不应该发生直接的相互调用，可以通过第三方来实现间接调用。其目的是为了降低类之间的耦合度，提高模块的相对独立性。
迪米特法则需要根据实际情况选择是否使用，过度使用迪米特法则会使系统产生大量的中介类从而导致系统复杂性提升，模块间通信效率降低。在实际开发中需要慎重权衡，在保证高内聚低耦合的同时使系统结构清晰。
