设计模式之七大设计原则

一、原则概述

定义：在进行软件系统设计时所要遵循的一些经验准则，应用该准则的目的通常是为了避免某些经常出现的设计缺陷。（百度百科） 目标：降低系统耦合度、提高代码复用率、增强系统可靠性或使得系统易于维护。

二、七大原则

（一）单一职责原则（Single Responsibility Principle）；

一个类应该有且仅有一种职责，此外应该只有一种原因让他改变。

不管是方法、类、类库、解决方案或者是这一个项目都需要符合单一原则。一个方法，我只处理一个功能逻辑。一个类，我只实现一个业务或者场景。一个类库，我的职责就是数据库啊或者工厂或者前端或者帮助类一个解决方案，就是后台系统就是后台系统，前台就是前台，或者定时服务，或者接口。

（二）开闭原则（Open Closed Principle）；

对修改关闭，对扩展开放。开闭原则是其他五个原则的基础，可以简单理解为：开闭是抽象类，其他五个是实现，是指导设计的工具和方法。

【示例】基础需求：汽车可以跑起来。追加需求：卡车、赛车；

（三）里氏替换原则（Liskov Substitution Principle）；

任何出现父类的地方都可以用子类替换，而不影响程序正常运行。核心是“约定”，父类与子类的约定。里氏替换原则要求子类在进行设计的时候要遵守父类的一些行为约定。这里的行为约定包括：函数所要实现的功能，对输入、输出、异常的约定，甚至包括注释中一些特殊说明等。

（四）迪米特法则（Law of Demeter）；

不要和陌生人说话（只与你的直接朋友通信）。迪米特法则又叫最少知道原则，即一个类对自己依赖的类知道的越少越好，对于依赖的类不管有多复杂，都尽量将逻辑封装在类的内部，对外除了提供public方法，不泄漏任何信息。

（五）接口隔离原则（Interface Segregation Principle）；

客户端不应该强行依赖它不需要的接口；类间的依赖关系应该建立在最小的接口上。

1、接口尽量小 2、接口高内聚 3、接口设计的限度（完全按此原则会导致接口数量暴增）

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

上层模块不应该依赖下层模块，两者应依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。依赖倒置的本质是利用抽象解耦迫不得已的依赖，使得依赖的下层模块的修改不会影响上层模块 【示例】场景：人驾驶汽车

（七）合成复用原则（Composite Reuse Principle，CRP）

尽量先使用聚合、组合来实现，之后再考虑使用继承。降低耦合度，将接口或者抽象类以聚合或者组合的方式引入，可以任意的灵活的去实现对应的子类。【示例】汽车按“动力源”划分可分为汽油汽车、电动汽车等；按“颜色”划分可分为白色汽车、黑色汽车和红色汽车等。如果同时考虑这两种分类，其组合就很多。

三、总结

(1)  单一职责原则：一个类或接口只承担一个职责。

(2)  开闭原则：对软件实体的改动，最好用扩展而非修改的方式

(3)  里氏替换原则：在继承类时，务必重写（override）父类中所有的方法，尤其需要注意父类的protected方法（它们往往是让你重写的），子类尽量不要暴露自己的public方法供外界调用。

(4)  迪米特法则：尽量减少对象之间的交互，从而减小类之间的耦合。

(5)  接口隔离原则：不要对外暴露没有实际意义的接口。

(6)  依赖倒置原则：高层模块不应该依赖于低层模块，而应该依赖于抽象。抽象不应依赖于细节，细节应依赖于抽象。