设计模式之路：七大设计原则

01 单一职责原则

定义：就一个类而言，应该仅有一个引起它变化的原因。

像我们一般业务开发中，主要就是注意每个模块都在自己的service层做业务，而不是在一个大的service中维护了好几个功能模块。

因为对一个类进行修改，我们就有可能改变了语义，造成代码需要进行回归测试，增加测试同学工作量，也让代码变得不够稳定。

02 开闭原则

定义：软件实体（类、模块、函数等等）应该可以扩展，但是不可以修改。

在我们面对需求时，对程序的改动是通过增加新代码而不是修改现有的代码。

主要是说，像我们在开发一些新的需求时，除非是那种明确对原来的实现需要进行变更的，那么我们就应该已继承的方式来实现新需求。

03 依赖倒置原则

定义：高层模块不应该依赖底层模块，两个都应该依赖抽象。抽象不应该依赖细节，细节应该依赖抽象。

我们在开发时，要针对接口编程，依赖于抽象而不依赖于具体的类。

04 里氏替换原则

定义：子类型必须能够替换掉他们的父类型。

任何基类可以出现的地方，其子类一定可以出现。

一般，在我们日常开发过程中，尽量保证不去修改基类的方法，子类只需要实现父类的抽象方法即可。

如果我们必须要重写父类的方法，那么我们应该做到入参比父类更严格，出参比父类更宽松，这样就可以保证原来调用父类的调用方依然可以调用父类，而不会去调用子类。

05 接口隔离原则

定义：使用多个专门的接口比使用单一的总接口要好。

主要是说，在日常开发过程中，我们定义一个有很多方法的接口，而且每个实现类都不需要实现所有的方法，那么这样就是一个违背接口隔离原则的代码。

我们应该拆分这个接口的方法，将粒度控制在每个实现类不需要实现自己不需要的方法即可。

06 迪米特法则

定义：也称为最少知道原则，一个对象应当对其它对象有尽可能少的了解。

和直接朋友对话，即只依赖于类的成员变量，方法的传入参数和返回值的类型。

不和陌生人对话，即在方法中不创建局部变量，除了 JDK 给我们提供的类。

07 合成复用原则

定义：要尽量使用合成/聚合，尽量不要使用继承。