设计模式的七大原则：
- 单一职能原则
- 定义：一个类只有一个引起发生变化的原因，即一个类只负责一个单一的职能。
- 举例：创建人员后，除了要保存到数据库，还要发送欢迎邮件，如果我们把保存到数据库和发送欢迎邮件都写在User类里面就违反了单一职能原则，User类只作为数据载体，保存数据库放到UserRepository里面，发送邮件放到EmailService里面
- 开闭原则
- 定义：对修改关闭，对扩展开放。当需求发生变更时，我们应该通过添加新代码来扩展功能，而不是在原有已稳定的代码上去做修改，
- 举例：有一个计算面积的功能，对于圆形、正方形、菱形 在一个方法里面通过if else的方式给出不同的处理逻辑是不合适的，而是应该通过接口或者抽象类的方式，定义不同的实现类，在实现类里面实现不同的业务处理逻辑。
- 里氏替换原则
- 定义：子类对象必须能替换掉所有的父类对象，而不能改变父类的行为。子类不能外破坏父类的逻辑契约
- 举例：经典的正方形不是长方形问题，如果长方形是父类，并且提供了设置长宽的方法，也提供了面积 = 长*宽的方法。如果我们正方形继承了长方形类，并且重写了设置长宽的方法，设置长或者设置宽的时候，都分别给宽和长设置成同一个值，那么原来父类的行为就被破坏。
- 接口隔离原则
- 定义：客户端对另一个类的依赖应该控制在最小粒度上。避免实现类被迫实现它们不需要的方法，防止出现胖接口。
- 举例：有一个接口Human，提供了工作、吃饭、洗澡等方法，有一个Robin类，实现了Human接口，那么Robin类就不得不实现他们不需要的吃饭和洗澡这类无用的方法。
- 依赖倒置原则
- 定义：上层业务模块不应该直接依赖底层的实现，双方应该都通过接口或者抽象的方式调用，面向接口编程而不是面向实现编程。
- 举例：*Repository 应该依赖DataSource。而不是MysqlDataSouerce。
- 最少知道原则
- 定义：一个对象应该减少对其他对象的了解，只关注和自身有直接关系的对象，
- 举例：不要使用链式调用过深，比如：A.getB().getC().doSomething();
- 组合复用原则
- 定义：尽量使用组合的方式来达到复用的目的，而不是通过继承的方式来实现。
- 举例：我们想要在Repository里面来打印日志，我们应该把日志Logger注入到我们目标类里面去，而不是使我们的Repository extend Logger.