六大设计原则及其使用场景
构成我们学习最大障碍的是已知的东西，而不是未知的东西
1.单一职责原则
即一个类只负责一个职责，例如现在比较流行的微服务，就是将一个复杂的耦合性很高的业务，拆分成多个独立的功能单一的接口，然后通过服务编排的方式实现不同的业务需求；
单一职责的好处：
- 类的复杂性降低，功能明确，可读性提高，可维护性和可扩展性提高；
- 变更引起的风险降低
2.开闭原则
开闭原则指的是对扩展开发，对修改关闭。它的意思是说我们在实现一个新的功能时，我们要想着在原有的基础上扩展，而不是去修改原有的功能！
例如:我们移动端的应用，随着版本迭代，我们不能强制要求我们的用户每次都去升级或者协助用户去升级，那么就要求新增的功能不允许在原有的接口上修改，而是要在原有的接口上进行扩展。
3.里氏替换原则
里氏替换原则是面向对象编程的实现基础，它的意思是所有引用了父类的地方都能被子类所替换，且不会引起任何的异常或错误；
例如:如果我们将鸵鸟归为鸟类，那么鸵鸟也是鸟的子类，但是鸟类会飞，而鸵鸟不会飞，那么鸵鸟这个子类就违背了里氏替换原则。
4.依赖倒置原则
依赖倒置原则指的是针对接口编程，而不是面向具体的实现编程；它的意思是我们在做一个功能时，应该依赖于高层面的实现，而不是依赖于底层的实现；即高层模块不应该依赖于底层的模块，因为底层的模块的职责单一，不足以应对高层模块的变动；
例如:我们我们打车从A地点出发前往B地点，我们只需要预约一个车就可以了，而这个车就是一个顶层的接口，它的实现类可以是各种各样的车，不同厂商的车，不同颜色的车。我们只需要依赖于这个顶层的车就可以了，而不是依赖于具体的某一个车，或者车牌号为“xxx”的车，一旦我们依赖于具体的车，那么这辆车被占用或者发生故障，那么就会对我们从A到B的行程产生影响。
5.接口隔离原则
接口隔离原则是对接口进行规范约束，它指的是使用多个专门的接口比使用单一的总结口要好，即接口应该是互相隔离的小接口，而不是复杂的大接口；
接口隔离原则包含四个定义：
- 接口要尽量小，这个小指的是不能违反单一职责原则。
- 接口要高内聚； 高内聚就是提高接口、类、模块的处理能力，减少对外的交互。在接口中尽量少公布public方法，接口是对外的承诺，承诺越少对系统的开发越有利，变更的风险也就越少，同时也越有利于降低成本。
- 定制服务；一个系统或系统内的模块之间必然会有耦合，有耦合就要有相互访问的接口（并不一定就是Java中定义的Interface，也可能是一个类或单纯的数据交换），我们设计时就需要为各个访问者（即客户端）定制服务。定制服务就是单独为一个个体提供优良的服务。我们在做系统设计时也需要考虑对系统之间或模块之间的接口采用定制服务。采用定制服务就必然有一个要求：只提供访问者需要的方法。
- 接口设计是有限度的。 接口的设计粒度越小，系统越灵活，这是不争的事实。但是，灵活的同时也带来了结构的复杂化，开发难度增加，可维护性低，这不是一个项目或产品所期望看到的，所以接口设计一定要注意适度，这个“度”如何来判断？根据经验和常识判断，没有一个固话或可测量的标准
例如:现在的微服务开发，各种服务间的调用，我们应该只暴露出对方需要的接口；
6.迪米特法则
迪米特法则又称最少知识原则，它是指一个类对于另一个类知道的越少越好。它设计的初衷是降低类之前的耦合度，每个类之前的联系少了，那么每个类都单独的处理自己的事，这样就能降低类之前的耦合性；只有弱耦合了以后，类的复用率才可以提高。其要求的结果就是产生了大量的中转或跳转类，导致系统的复杂性提高，同时也为维护带来了难度。
例如:电影中看到的，有些人在遇到强盗时会选择闭着眼睛不看强盗，因为这样知道的越少对自己来说越安全！
