github地址
类、模块、函数应对扩展开放，修改关闭。
喝水共用水杯，将喝水的材料中药变为水
高层模块不应该依赖于低层模块，二者应该依赖于抽象，抽象不应该依赖于细节，细节应该依赖于抽象。
A-B是一对情侣，但A又喜欢C、D、E，这些都在A中有所实现，B必须问A，A才会告诉B这些细节，但是B又想A只喜欢他，想控制他，让他喜欢谁就喜欢谁，就让A实现接口，B对这个接口传入什么A就喜欢什么
不要存在一个以上导致类变更的原因，假设一个class负责两个职责，一旦发生需求变更，修改一个职责的逻辑代码，又可能导致另一个功能发生故障，则需两个class类来实现两个职责，进行解藕。
喝中药的杯子，若两用麻烦，还要洗
用多个专门的接口，而不是使用单一的总接口，客户端不应该依赖它不需要的接口。
喝水，喝中药。不舒服的时候应喝中药，不应全部依赖。
一个对象应该对其他对象保持最少的了解，尽量降低类与类之间的耦合，强调与朋友交流，不和陌生人说话。
喝中药跟水，若只能有一个杯子，则中药喝完后处理完了再去接水，不能在喝水的途中又处理中药。杯子是容器，我们的引用，中药跟水是不同的处理。类似于controller跟service,我只传递返回值的引用，将业务操作都在service进行处理
子类可以扩展父类的功能，但不能改变父类原有的功能。
针对于水杯，我们既可以喝中药也可以喝水
尽量使用对象组合或对象聚合的方式实现代码复用，而不是用继承的关系达到代码复用的目的
杯子既装中药又装水，都叫水杯，将其作为抽象类，两种不同的实现
依赖倒置原则
1.杯子是一个事物，一个类，作为一个容器（抽象类）有基本的功能，他有许多的实现，如水杯，茶水杯，调用do就调用相应的类——合成复用原则
2.现在把他当作一个功能看待，接中药跟水，之前是接中药的，现在我要接水了，我直接继承这个中药类，可以直接修改里面对应方法的代码——开闭原则
3.但是现在把代码修改了，我就不能喝中药了，只能重新new一个中药类，那么我就不覆盖，添加一个方法，将一个水杯既能喝水又能喝中药——里氏替换原则
4.喝水跟喝中药是两个功能，但是现在同学觉得水里面有中药的味道不舒服，所以这两个接口不能写在一起，否则总有一个接口为空，所以要拆开，需要什么功能为就将该类继承某个接口——接口隔离原则
5.但是现在只有一个水杯，又要喝中药又要喝水，那么一定是将中药洗干净后再装水，不能在装水的过程中又要处理中药，传递的只是杯子。——迪米特法则
6.那么最好的解决办法就是2个杯子，分成两个类。一个装水，一个装中药——单一职责
