可修改性战术

4.可修改性战术

软件怎样具有可修改性，这里将介绍两种战术。

首先说明一下可修改性战术。可修改性战术的目标是控制实现、测试和部署变更的时间和成本。在具体的解释为根据相关战术，策略在时间和成本允许的范围内完成系统的相关变更。

以下讨论两种可修改性战术：局部化修改和防止连锁反应

局部化修改战术，目标是把变更限制在一定范围，在设计期间为模块分配职责，把预期变更限制在一定范围内。关键点就是“限制变更范围”防止变更的内容对其他内容（或者说程序）产生影响。

防止连锁反应。我们平时编程无论是写函数还是写类，都会被其它的类或函数（方法）调用，如何实现对被调用部分的修改不会引起对调用它的部分的影响，这就是可以防止连锁反应。

无论是局部化修改还是防止连锁反应，都是基于“高内聚，低耦合”思想。那么根据软件设计模式的设计原则来分析：

（1）局部化意味着实现“模块化”思想，这里模块这样解释，一个模块只完成一个部分，这就符合设计模式中“单一职责原则”的设计原则，使每一个模块责任单一，防职责过多引起引起整体变更时的繁琐，复杂；

（2）要符合“接口隔离”设计原则，为后期的变更提供接口，当然也要规定接口调用的规范。同时根据“里氏代换”原则将接口的实例化由接口实现类完成，在此之上基于“依赖倒转原则”搭建的上层服务如果需要修改相关服务可以实现局部化修改，不用再对上层服务进行修改。在防止连锁反应的战术中“维持现有接口”就是为上层服务提供一个可使用的接口，当进行变更时对接口的实现类变更即可，无论是实现“适配器”还是“信息隐藏”都可封装在接口实现类中。

（3）降低模块之间的依赖性是防止连锁反应的必要条件。可据“迪米特法则”来实现。所谓“迪米特法则”，在C++中可理解为“友元”，java理解：在类与类间加入第三方类作为沟通，信息交流的“缓冲”，两个类间不直接相互依赖。这种第三方类可叫做“朋友”，可叫做“仲裁者”。在设计模式中可表示为“桥”“调停者”“代理”“工厂”，这些都是为了降低类间依赖。当然这又产生一个问题：大量使用第三方类使程序繁琐，复杂，这就需要架构师设计好一个明确的类图了。

以上基于软件设计模式分析了两个可修改性战术。