【菜鸟日记】软件构造笔记 6.1 面向可维护性的软件构造方法（详细版）

6.1.1 软件维护的基本概念

软件维护的类型

• 纠正性维护
• 适应性维护
• 完善性维护
• 预防性维护
  ps:尽量保证软件的熵值较小，当熵值变大时，要注意修补使熵值变小。

评价软件可维护性的指标

• 易于纠正错误和提升性能
• 易于增加功能
• 易于改变
• 适应用户个性化需求
• 发布后，软件受支持的程度常用的

常用的软件可维护性指标

1. 独立路径的个数 ：越多，软件可维护性越差，需要测试的数据越多
   ps:独立路径仅与不同的点的个数有关，和产生的环的圈数多少无关，一圈和两圈效果相同。（下图中R1出现一次和两次为同一个独立路径）

2. 运算符和操作数的数目
3. 可维护性指数（MI）：越大可维护性越好
4. 继承的深度：越深可维护性越差
5. 类耦合度：好的软件应该是高内聚，低类耦合
6. 单元测试覆盖率高

一些其他的指标

6.1.2设计模块的原则

评估模块性的五个标准

• 可分解性：将问题分解为各个可独立解决的子问题，使模块之间的依赖关系显式化和最小化
• 可组合性：可容易的将模块组合起来形成新的系统，使模块可在不同的环境下复用
• 可理解性：每个子模块都可被系统设计者容易的理解
• 可持续性：规格说明小的变化将只影响一小部分模块，而不会影响整个体系结构
• 保护性：运行时的不正常将局限于小范围模块内

模块设计原则

• 直接映射：模块的结构与现实世界中问题领域的结构保持一致，不考虑计算机的底层实现（影响持续性和可分解性）
• 尽可能少的接口：模块应尽可能少的与其他模块通讯（影响可持续性、保护性、可理解性、可组合性）
• 尽可能小的接口：如果两个模块通讯，那么它们应交换尽可能少的信息（影响可持续性和保护性）
• 显式接口：当A与B通讯时，应明显的发 生在A与B的接口之间
• 信息隐藏：经常可能发生变化的设计决策应 尽可能隐藏在抽象接口后面

巧记

6.1.3内聚性和耦合性

左边低内聚高耦合，有边高内聚低耦合，右边更好

6.1.4 SOLID

SOLID的含义：

(SRP) The Single Responsibility Principle ：单一责任原则

类中的方法必须要有紧密的联系

(OCP) The Open-Closed Principle: 开发封闭原则

OCP的含义：对扩展开放，对修改封闭，通过继承和组合改变/扩展功能
举一个反例：这个不利于扩展，一旦要扩展必须有要修改之前的类
整体替换

(LSP) The Liskov Substitution Principle ：Liskov替换原则

子类型必须能够替换其基类型，有一个反例：基类型中setWidth只改变m_width,而在子类型中m_height也被改变了，所以它不能替换基类型中的setWidth；SetHeight同理

(ISP) The Interface Segregation Principle ：接口替换原则

接口尽可能的小，如果接口中有用户用不上的接口，应该去掉。比如：机器人不应该有eat的选项，eat应该作为worker的私有方法

(DIP) The Dependency Inversion Principle ：依赖转置原则

6.1.5 GRASP:通用责任分配软件模式（原则）