三：设计模式的六大原则

一：单一职责原则
描述：对一个类而言，引起它变化的原因应该只有一个。如果仅仅理解为“功能单一”就太抽象了，没有具体的标准。
举个例子（知乎上的例子）：
假定现在有如下场景：国际手机运营商那里定义了生产手机必须要实现的接口，接口里面定义了一些手机的属性和行为，手机生产商如果要生产手机，必须要实现这些接口。
版本1：设计一个手机接口，把手机的属性和行为（打电话，接电话，上网）都放在里面，生成手机就要实现这个接口。
但是如果随着手机的发展，手机多了一个摄像头的属性，所以这个设计是有问题的，粒度划分太粗。
版本2：把手机接口拆成手机属性接口和手机功能接口
但是老年机没有不能上网啊，所以这个设计是有问题的，粒度划分还是太粗。
版本3：把基础属性和其它属性在拆分一下，基础功能和高级功能也分开。
以上通过一个应用场景简单介绍了下单一职责原则的使用，上面三种设计，没有最合理，只有最合适。理解单一职责原则，最重要的就是理解职责的划分，职责划分的粒度取决于需求的粒度，最后又回到了那句话：没有最好的设计，只有最适合的设计。
连接：https://zhuanlan.zhihu.com/p/24198903

二：开闭原则
通过扩展来实现变化，而不是通过修改已有的代码来实现变化。开闭原则是最基础的一个原则，其它5个原则都是开闭原则的具体形态，而开闭原则才是其精神领袖。这个就不多说了。

三：里式替换原则
1.通俗点讲，就是只要父类能出现的地方，子类就可以出现，而且替换为子类也不会产生任何错误或异常。
2.子类可以扩展父类的功能，但不能改变父类原有的功能

四：依赖倒置原则
面向接口编程，而不是面向细节编程。抽象不应该依赖细节，细节应该依赖抽象。

五：迪米特原则
迪米特法则（LoD）也叫最少知道法则：一个对象应该对其他对象有最少的了解。

六：接口隔离原则
官方翻译：其一是不应该强行要求客户端依赖于它们不用的接口；其二是类之间的依赖应该建立在最小的接口上面。简单点说，客户端需要什么功能，就提供什么接口，对于客户端不需要的接口不应该强行要求其依赖；
即客户端需要什么接口，就依赖什么接口，不需要的就不依赖。那么我们反过来说，如果客户端依赖了它们不需要的接口，那么这些客户端程序就面临不需要的接口变更引起的客户端变更的风险，这样就会增加客户端和接口之间的耦合程度，显然与“高内聚、低耦合”的思想相矛盾。
接口隔离原则和单一职责原则
从功能上来看，接口隔离和单一职责两个原则具有一定的相似性。其实如果我们仔细想想还是有区别的。

（1）从原则约束的侧重点来说，接口隔离原则更关注的是接口依赖程度的隔离，更加关注接口的“高内聚”；而单一职责原则更加注重的是接口职责的划分。

（2）从接口的细化程度来说，单一职责原则对接口的划分更加精细，而接口隔离原则注重的是相同功能的接口的隔离。接口隔离里面的最小接口有时可以是多个单一职责的公共接口。

（3）单一职责原则更加偏向对业务的约束，接口隔离原则更加偏向设计架构的约束。这个应该好理解，职责是根据业务功能来划分的，所以单一原则更加偏向业务；而接口隔离更多是为了“高内聚”，偏向架构的设计。