设计模式基本原则及其作用
单一职责原则
每个类和接口都应该是功能职责单一的，在实际应用上，我们应该保证接口职责单一，类尽量做到职责单一
好处：
- 类的复杂性降低，实现什么职责都有清晰明确的定义
- 复杂性降低—>可读性提高—>可维护性提高
- 变更引起的风险降低，如果接口的单一职责做得好，那么接口的修改只会对相应的实现类造成影响，对其他接口没有影响，对系统的扩展性、可维护性都有帮助
里氏替换原则
所有父类出现的地方，子类都可以出现，并且运行结果（或者说被调用的方法）与父类出现时候保一致
好处：
增强程序的健壮性，版本升级的时候可以保持非常好的兼容性，即使增加子类，原有的子类还可以继续运行。LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。
保证兼容性手段：（契约性设计）
尽量不用重写父类方法，子类重载时参数可放大不可缩小。
依赖倒置原则
高层模块之间应该互相依赖其抽象，抽象不应该依赖细节，细节应该依赖抽象
好处：
- 松耦合：通过抽象使各个类或模块的实现彼此独立，实现类或模块间的松耦合，同时屏蔽细节对抽象的影响
- 提高系统的稳定性：被依赖者不应该让依赖者承担其扩展时候带来的影响，因为使用依赖倒置，通过接口可以避免扩展实现带来的影响
- 降低并行开发引起的风险：不使用依赖倒置的环境中，所有开发都是单线程的
接口隔离原则
客户端不应该依赖它不需要的接口（类间的依赖关系应该建立在最小的接口上）
好处：
通过分散定义多个接口，可以预防未来变更的扩散，提高系统的灵活性和可维护性。
单一职责与接口隔离对比：两者审视的角度不同
单一职责注重业务逻辑的划分；接口隔离注重接口的方法应该尽量少，只暴露别人需要的部分
根据接口隔离原则划分接口的时候，首先必须满足单一职责原则
迪米特法则
一个对象应该对其他对象有最少了解（只与朋友类交流、两部分之间的交流做适当的控制）
好处：
弱耦合
（弱耦合可以使得类的复用率提高，但是会产生大量的中转类，导致系统复杂性的提高）
开闭原则
一个软件实体应该对扩展开放，对修改关闭
前面五个原则是对开闭原则的具体解析，开闭原则是一个比较虚的原则。
好处：
在对扩展开放的同时，尽量减少对原有代码的修改，保持历史代码的纯洁性，提高系统的稳定性
