《嵌入式软件设计方法》--设计原则

设计原则（SOLID）

使用各个原则的首字母组成了一个单词:SOLID。

• SRP:Single Responsibility Principle，单一职责原则；
• OCP:Open Closed Principle，开闭原则；
• LSP:Liskov Substitution Principle，里氏替换原则；
• ISP：Interface Segregation Principle，接口隔离原则；
• DIP:Dependence Inversion Principle，依赖倒置原则。

1. 单一职责原则（SRP）

1.1 定义

但一职责原则（Single Responsibility Principle）的定义：“就一个类而言应该仅有一个引起他变化的原因”。
该原则的亮相状态是：类只应该承担一个责任。如果一个类承担的多个责任，那么引起他变化的原因就越多，就降低了类的稳定性。
SRP强调类不应该承担太多的职责。唯有专注才能保证高内聚，唯有单一才能保证细粒度。高内聚和细粒度也更利于软件的重用。

1.2 SRP对方法设计的影响

单一职责原则适合于接口，类，同样也使用于一般的方法（函数），即一个方法也尽可能只做一件事情。

1.3 小结

遵循单一职责的好处：

• 类的复杂性降低：实现了什么职责都有明确的定义。
• 可读性提高：职责清晰明了，类的设计简单，易读易理解。
• 可维护性提高：职责单一后，依赖关系更加简单，维护起来也更加容易。
• 变更引起的风险降低：不会引入额外的依赖，每次变更不会引起大量的测试验证。
  实际应用中，应该根据实际情况使用SRP,在职责不容易划分时，不必强求，首先以最简单的方法实现，直到“变化的原因”产生时，再继续迭代，优化程序设计。

2. 开闭原则（OCP）

2.1 定义

​ 开闭原则（open closed principle）：“一个软件实体（类、模块、函数等等），应该对扩展开放，对修改关闭”。
​ 一个软件只要在生命周期内，就有可能发生变化。软件设计时尽量适应这些可能的变化，以提高软件的稳定性和灵活性。开闭原则用于指导我们设计的软件应该如何实现变化，主要包括：

1. 对扩展开放

表示软件是可以扩展的。一个软件实体应该尽可能地扩展来实现变化，改变软件实体的功能，即通过添加新的代码来满足那些改变的新行为。
2. 对修改关闭

这里的不可修改指的是不能通过修改已有的代码来完成变化。
正确的使用OCP，可以在软件变化时，只需要添加新的代码，而不必更改已经正常运行的代码。这很好的的避免了大规模的测试、部署和重构。
开闭原则的目的时拥抱可能的变化。而变化的软件在设计之初并没有显现出来。因此，开闭原则是为软件实体的未来事件而制定的对现行开发设计进行约束的一个原则。

2.2 小结

​ 开闭原则是一个基础的原则，是总的设计直到思想。创建正确的抽象是要花费时间和精力的，同时，大量的抽象也增加了软件设计的复杂性。拒绝不程序的抽象和抽象本身一样中重要。

3. 里氏替换原则（LSP）

3.1 定义

如果对应每个类型为S的对象O1,都存在一个类型为T的对象O2,使得所有针对类型T变形的程序P中，用O1替换O2后，程序P的行为没有发生变化，那么类型S就是类型T的子类型。

一种更通俗的说法：**所有引用基类的地方，必须能都透明的使用其子类的对象。**只要父类出现的地方，子类就可以出现，而且替换子类不会产生任何错误或者异常，使用者可能根本不需要直到传递过来的对象究竟是子类对象还是父类对象。

3.2 基于契约设计

LSP强调"可替换性"。可以将父类及其接口看作一种契约，针对父类的某一方法，其制定了一种契约，即该方法的**“前置条件”和"后置条件"**。前置条件是执行方法的前提，可以看作对输入的契约；后置条件的该方法对外的反馈，可以看作是对输出的契约。

为了保证子类对于父类的可替换性，子类的前后置条件需要满足如下规则

• 前置条件
  相比于父类的某一方法，子类的前置条件只能相等或更弱，条件范围扩大。
• 后置条件
  相比于父类的某一方法，子类的后置条件只能相等或更强，条件范围缩小。

3.3 小结

采用里氏替换原则的目的是为了避免继承的滥用，进而增强程序的健壮性，使软件升级时也可以保持非常好的兼容性。应用程序基于父类进行编程，即使增加子类或者修改子类也不会对应用程序造成影响。

4. 接口隔离原则（ISP）

4.1 定义

接口隔离原则有如下两种定义：

1. “客户端不应该依赖他不需要的接口”；
2. “类间的以来关系应该建立在最小的接口之上”；

4.2 小结

ISP 强调“类或模块不应该依赖于它们不会使用的方法”。如果依赖了那些它们根本不
会使用的方法，那么这些类或模块就会陷入一种窘境：当那些根本不会使用的方法发生变更
时，也会对模块或类产生影响，这极大的增加了类与类之间的耦合，致使每一次方法变更的
影响范围很大，难以维护。分离接口是针对这类问题的一种很好的解决方案。
ISP 实际应用起来比其它几个原则相对来讲都要容易一些。在实际应用中，如果一些接
口类中包含了过多的方法，就应该根据实际应用场合，考虑将接口拆分，以杜绝不必要的依
赖关系，进而降低模块之间的耦合。
ISP 要求接口是微小的、纯洁的、没有冗余的，不应该出现臃肿的接口（Fat Interface）。
实际上，接口就是对外的一种“承诺”，接口越小，承诺也就越少，变更的风险也就越小，
对系统的开发也就更加有利。但是接口的“小”是有限度的，试想一下，既然要求小，那就
直接设计到“最小”：每个接口类只包含一个方法。

5. 依赖倒置原则（DIP）

5.1 定义

1. 高层模块不应该依赖于低层模块，两者都应该依赖于抽象；
2. 抽象不应该依赖于细节；
3. 细节应该依赖于抽象；

5.3 小结

依赖倒置原则的本质就是通过抽象使各个类或模块实现彼此独立，互不影响。特别是解
决了在传统嵌入式开发中，高层模块经常依赖于低层模块（例如具体芯片、硬件模块等）的
现状，使开发出跨平台的应用程序成为可能。
“依赖倒置原则”倒置了接口所有权，低层模块不再向高层模块提供自己的 API（高层
模块不直接调用低层模块），而是由高层模块定义接口类，接口的所有权属于高层模块，低
层模块只是按照接口类的要求进行实现而已。