介绍
设计模式中的SOLID原则，分别是单一原则、开闭原则、里氏替换原则、接口隔离原则、依赖倒置原则。前辈们总结出来的，遵循五大原则可以使程序解决紧耦合，更加健壮。
思维导图：从封装、继承的角度考虑七大原则的关系：
单一职责原则（Single Responsibility Principle）：
定义：就一个类而言，应该仅有一个引起它变化的原因。
优点：
类的复杂性降低。类的职责单一，复杂性自然就降低了。可读性高。易维护。变更引起的风险降低。
开放封闭原则（open closed principle）：
开闭原则（OCP）是面向对象设计中“可复用设计”的基石，是面向对象设计中最重要的原则之一，其它很多的设计原则都是实现开闭原则的一种手段。
定义：软件实体（类、模板、函数等等）应该可以扩展，但是不可修改。
简单的说就是，当一个软件实体需要扩展的时候，不要去修改原有的代码，而是去扩展原有的代码。其实开闭原则是最基础的一个原则，下面六个原则都是开闭原则的具体形态。
特点：
对于拓展是开放的（open for extension）对于更改是封闭的（closed for modification）
使用开闭原则的理由：
第一：开闭原则非常有名，只要是面向对象编程，在开发时都会强调开闭原则
第二：开闭原则是最基础的设计原则，其它的五个设计原则都是开闭原则的具体形态，也就是说其它的五个设计原则是指导设计的工具和方法，而开闭原则才是其精神领袖。依照java语言的称谓，开闭原则是抽象类，而其它的五个原则是具体的实现类。
第三：开闭原则可以提高复用性
在面向对象的设计中，所有的逻辑都是从原子逻辑组合而来，不是在一个类中独立实现一个业务逻辑。只有这样的代码才可以复用，粒度越小，被复用的可能性越大。那为什么要复用呢？减少代码的重复，避免相同的逻辑分散在多个角落，减少维护人员的工作量。那怎么才能提高复用率呢？缩小逻辑粒度，直到一个逻辑不可以分为止。
第四：开闭原则可以提高维护性
一款软件量产后，维护人员的工作不仅仅对数据进行维护，还可能要对程序进行扩展，维护人员最乐意的事是扩展一个类，而不是修改一个类。让维护人员读懂原有代码，再进行修改，是一件非常痛苦的事情，不要让他在原有的代码海洋中游荡后再修改，那是对维护人员的折磨和摧残。
第五：面向对象开发的要求
万物皆对象，我们要把所有的事物抽象成对象，然后针对对象进行操作，但是万物皆发展变化，有变化就要有策略去应对，怎么快速应对呢？这就需要在设计之初考虑到所有可能变化的因素，然后留下接口，等待“可能”转变为“现实”。
里氏替换原则（LSP liskov substitution principle）：
定义：所有引用基类的地方都必须能透明地使用其子类的对象。
继承的优点：
代码共享，提高代码的重用性。提高代码的可扩展性。提高产品或者项目的开放性。
继承的缺点：
继承是侵入式的，只要继承，就拥有了父类的属性和方法。降低代码灵活性，子类拥有了父类的属性和方法，多了一些约束。增强了耦合性。父类的常量、变量或方法改动时，必须还要考虑子类的修改，可能会有大段代码需要重构。
里氏替换原则四层含义：
子类必须完全实现父类的方法
在类中调用其他类时务必使用父类或接口，如若不能，则说明类的设计已经违背LSP原则。
如果子类不能完整的实现父类的方法，或者父类的方法在子类中发生畸变，这建议断开父子继承关系，采用依赖、聚集、组合等方式代替继承。子类可以有自己的特性：即子类出现的地方父类未必可以出现。覆盖父类的方法时输入参数可以被放大：输入参数类型宽于父类的类型的覆盖范围，例如 hashmap -> map。覆盖父类的方法时输出参数可以被缩小
接口隔离原则（interface segregation principle）：
定义：客户端不应该依赖他不需要的接口，类之间的依赖关系应该建立在最小的接口上。
四层含义：
接口尽量要小，不要出现臃肿的接口。接口要高内聚。只提供访问者需要的方法：每个接口中不存在子类用不到却必须实现的方法，如果不然，就要将接口拆分。接口设计是有限度的：接口设计粒度越小，系统越灵活。但是结构会越复杂、开发难度增加，可维护性降低。
依赖倒置原则（dependence inversion principle）：
面向接口编程；（通过接口作为参数实现应用场景）
理解：抽象就是接口或者抽象类，细节就是实现类
两层含义：
上层模块不应该依赖下层模块，两者应依赖其抽象；
抽象不应该依赖细节，细节应该依赖抽象；
第六大原则：
迪克特法则（最少知道原则）（Least Knowledge Principle，LKP）
定义：一个对象应该对其他对象有最少的了解（低耦合）。
三层含义：
一个类只与朋友交流，不和陌生类交流，方法尽量不引入类中不存在的对象。尽量不要对外暴露过多的 public 方法和非静态的 public 变量，尽量内敛。自己的就是自己的。如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放置在本类中。
总结：
迪米特法则的核心观念就是类间解耦，低耦合。其负面影响就是产生了大量的中转或者跳转类，导致系统复杂性提高，也为维护带来了难度。需要反复权衡，既做到结构清晰，又要高内聚低耦合。
如果一个类需要跳转两次以上才能访问到另一个类，就需要想办法重构了。
