设计模式（一）

五大设计原则

单一职责原则（SRP）

SRP是五大设计原则中最易被误解的一个。很多人想当然地认为这个原则就是指：每个模块都应该只做一件事。其实这只是SRP的部分。
《架构整洁之道》一书这样描述：任何一个软件模块都应该只对某一类行为者负责。 “软件模块”指一组紧密相关（与某一类行为者相关组合在一起）的函数和数据结构。
下面举个例子：

Employee类中reportHours函数和calculatePay函数共同调用同一个时长计算函数

此时如果因为reportHours方因为某些原因需要对regularHours修改，那么如果没考虑到calculatePay方，那么修改后很大几率会导致clculatePay方产生异常。这是一个典型的没有遵守单一职责原则的案例。可以采用外观行为模式对其重构。并将数据与函数分离。

开闭原则（OCP）

该设计原则认为：设计良好的计算机软件应该易于拓展，同时抗拒修改。
按照OCP原则，在软件设计过程中应将系统划分为一系列组件，并且将这些组件间的依赖关系按层次结构进行组织，使得高阶组件不会因低阶组件被修改而受到影响。对于层次越高的组件，需要修改的次数应该越低，最高级的应当修改率为0。

里氏替换原则（LSP）

该设计原则定义如下：这里需要的是一种可替换性：如果对于每个类型是S的对象o1都存在一个类型为T的对象o2，能使操作T类型的程序P在用o2替换o1时行为保持不变，我们就可以将S称为T的子类型。
C++中继承机制就是这一原则的很好体现。

接口隔离原则（ISP）

该设计原则认为：任何层次的软件设计都不应该依赖本身并不需要的东西。
深刻体现这一原则思想的是微服务的思想，在合适范围内降低耦合度。

依赖反转原则（DIP）

这一原则定义：在源代码层次的依赖关系中应该多引用抽象类型，而非具体实现。
针对该原则，我们应该遵循以下编码守则：

• 应在代码中多使用抽象接口，尽量避免使用那些多变的具体实现类
• 不要在具体实现类上创建衍生类
• 不要覆盖包含具体实现的函数
• 应避免在代码中写入与任何具体实现相关的名字或者是其他容易变动的事 物的名字