设计模式六大原则

一、单一职责（Single Responsibility Principle）

理解

• 单一职责适用于接口、类、方法，只负责一项职责

优点

• 降低类的复杂度，一个类只负责一项职责，逻辑简单
• 提高类的可读性
• 可维护性提高：可读性提高，那当然更容易维护了
• 降低变更引起的风险：如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

二、开闭原则

理解

• 一个软件实体如类、函数应该对扩展开放，对修改关闭。

优点

• 提高代码复用性
• 提高可维护性

三、迪米特法则（Law of Demeter）

理解

• 又名最少知道原则
• 一个类对自己依赖的类知道的越少越好，也就是对于被依赖的类的方法和属性尽量私有化

四、接口隔离原则（Interface Segregation Principle）

理解

• 建立单一接口，不要建立庞大臃肿的接口
• 接口尽量细化，同时接口中的方法尽量少
• 一个接口只服务于一个子模块或业务逻辑

五、里氏代换原则（Liskov Substitution Principle）

理解

• 所有引用父类的地方必须能透明地使用其子类的对象，反过来则不成立

六、依赖倒置原则 （Dependence Inversion Principle）

理解

• “面向接口编程“是依赖倒置原则的核心，上层定义接口，下层实现这个接口， 从而使得下层依赖于上层，降低耦合度
• 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的

依赖倒置原则的具体实现：依赖注入（Dependency Injection）

• 构造函数传递依赖对象
• Setter方法传递依赖对象

应用场景

业务逻辑层相对于数据层是高层模块，因为业务逻辑层需要调用数据层去操作数据库，但是要做到将来变更数据库后业务逻辑层查库代码的改变，由业务逻辑层定义数据查询接口并交由底层数据层实现，通过依赖注入的方式将底层数据层类的实例注入到业务逻辑层即可。