质量属性：可修改性

目录

一、概念

二、场景

1、通用场景

2、特定场景

三、可修改性的策略

1、目标

2、策略

---

一、概念

可修改性（Modifiability）是关于变更的，关注变更的成本和风险。同时需要考虑：

• 可以变更什么
• 变更的可能性
• 什么时候以及谁做出变更

二、场景

1、通用场景

刺激源	最终用户、开发人员、系统管理员
刺激	一种用来添加/删除/修改功能，或更改质量属性、容量或技术的指令
制品	代码、数据、接口、组件、资源、配置、……
环境	运行时、编译时、构建时、启动时、设计时
响应	以下的一个或多个： 1）进行修改 2）测试修改 3）部署修改
响应衡量	以下的一个或多个： 1）受影响工件的数量、大小、复杂性 2）努力 3）日历时间 4）资金（直接支出或机会成本） 5）此修改会影响其他功能或质量属性的程度 6）新缺陷的引入

——翻译自《软件架构实践》一书Chapter7的general scenario

 2、特定场景

开发人员希望通过在设计时修改代码来更改用户界面。这些修改在3小时内没有任何副作用。

——翻译自《软件架构实践》一书Chapter7的specific scenario

刺激源	开发人员
刺激	更改用户界面
制品	代码
环境	设计时
响应	进行修改和测试修改
响应衡量	在3个小时内没有副作用

三、可修改性的策略

1、目标

控制变更的复杂度，以及变更的成本和时间。

 2、策略

1）减少模块的大小（Reduce Size of a Module）

• 拆分模块（Split module）：包含了大量的能力模块的修改成本可能很高。将模块细化成几个较小的模块来降低未来变更的平均成本。

2）增加内聚（Increase Cohesion）

• 增加语义一致性（Increase Semantic Coherence）：如果一个模块中的职责a和B没有达到相同的目的，那么应该将它们放在不同的模块中。

3）减少耦合（Reduce Coupling）

• 封装（Encapsulate）：封装为模块引入了一个显示接口，这个接口包括了一个API以及其相关职责。
• 使用中介（Use an Intermediary）：A和B之间存在依赖关系，使用中介可以打破。
• 限制依赖（Restrict Dependencies）：限制给定模块相互交互或依赖的模块。
• 重构（Refactor）：重构是当两个模块受到相同变化影响时采取的一种策略，因为它们是（至少是部分的）重复。
• 抽象公共服务（Abstract Common Services）：如果两个模块提供相似的服务，则仅以更一般的抽象形式实现，对公共服务的任何修改都只需要在一个地方进行。

4）延迟绑定（Defer Binding）：越晚绑定值越好，但是越昂贵。