总原则：开闭原则
解释：对扩展开放，对修改关闭。
案例：书店打折
首先定义一个book的接口，其中有getPrice方法，获取价钱。然后实现类novelBook实现book的接口。在上线一段时间之后，书店打算打折出售小说。
这个时候我们的方案有如下三种：
- 给book接口增加一个打折的方法，但是仅仅有一种书要打折，我们就要求全部种类的书都要实现打折方法，这个方案显然是行不通的。
- 修改novelbook的getPrice方法，但是我们也有需要获取原价的需求，这个方案显然也不是很友好
- 写一个offNovelBook的类继承novelBook，增加getoffPrice方法。这个方案可以让我们在不修改原有系统的基础上去实现变化。此方案可行。
单一职责
解释：一个类中只有一种职责，引起类中发生变化的原因也只有一类
案例：手机
在没有遵循单一职责的时候，我们这样设计手机。
有两个接口，分别是音乐播放器接口和拍照接口。手机类实现这两个接口。如果我对拍照的需求改变了，那么我会去修改手机类，测试的时候是不是也要测试音乐播放功能。相同的，如果我对音乐播放器的需求发生改变，拍照的功能是否会改变这个真的不好说。
实现单一职责的时候我们是这样设计手机的。
有两个接口，分别是音乐播放器接口和拍照接口。还有两个实体类，分别实现了各自的接口。手机实体类拥有这两个实体类。那么我拍照需求改变了，我就去更改拍照的实体类，音乐播放器的需求改变了，我就去修改音乐播放器的实体类，各自互不影响。
附加说明：这个原则是工程师下意识都会遵守的，并不会很难。难就难在需求的变更，导致了原本只有一个职责的类变更为有两个或以上的职责。这个时候是否需要遵守这个原则就得见仁见智了。
里氏替换原则
解释：只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新
案例：矩形和长方形
定义一个四边形的接口，他有长和宽两个属性。矩形类实现四边形接口，并且提供计算体积的方法。长方形都继承矩形类，并且提供计算周长的方法。那么只要是矩形出现的地方，我们都可以用长方形类来代替，并且不影响使用。
如果不遵守里氏替换原则：
那么在长方形类继承矩形类的时候，覆盖掉计算面积的方法，那么当子类代替父类的时候，方法会发生变化，这样就不符合里氏替换原则了。
依赖倒转原则
解释：模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的
案例：司机与汽车
司机有一个开车的方法，参数是奔驰汽车类。这样司机和奔驰汽车就发生了耦合。如果那一天司机不想开奔驰了，想开宝马，新建了一个宝马类，但是司机并不能开宝马，因为司机已经和奔驰汽车发生了耦合。
根据依赖倒转原则是这样写的代码
汽车有一个接口类，司机有一个开车的方法，参数是汽车的接口类。这样只要让奔驰和宝马实现汽车的接口类，司机就可以开奔驰和宝马了。甚至五菱宏光实现了汽车的接口类，司机还能成为秋名山的老司机。
接口隔离原则
解释：接口中不应该存在子类用不到却必须实现的方法
案例：程序员和网站
假设做网站需要两个步骤，第一步是前端程序设计，第二步是后端程序设计，那么设计一个接口，里面有两个方法，一个是前端程序设计，一个是后端程序设计。那么全栈工程师可能就一个人完成了网站的设计。那如果是专注后端的程序员可能就不需要实现前端程序设计了。这就违背了接口隔离原则。
应该这么设计：设计两个接口，将前端程序设计和后端程序设计分离开。这就是接口隔离了。这样就避免了让后端程序员承担不实现前端程序设计的风险了。
迪米特原则
解释：一个软件实体应当尽可能少的与其他实体发生相互作用。每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。
案例：
在没有遵循迪米特原则的时候，我可能和很多人发生交流，因此我会去了解和适应不同的人，迪米特法则告诉我们，我们应该只和密切相关的人发生交流。如图：
