可修改性战术的目标是控制实现、测试和部署变更的时间和成本。解释为根据相关战术，策略在时间和成本允许的范围内完成系统的相关变更。
可修改性是有关变更的成本问题。它提出了两个关注点：
-
可以修改什么（制品）？
可以修改系统的任何方面 ，最常见的就是系统计算的功能、系统存在平台（硬件、操作系统和中间件等 ）、系统运行的环境（它必须与之互操作的系统，它用于与其他部分进行通信的协议，等等）、系统所展示的质量属性（其性能、可靠性、甚至包括将来的可修改性）以及其容量（所支持的用户数量、同时发生的操作的数量，等等）。 -
何时进行变更以及由谁进行变量（环境）？
最常见的就是修改源代码。也就是说，开发人员必须修改代码，对修改后的代码进行测试，然后将其部署在新版中。然而，现在不仅仅是何时变更的问题，而且还有由谁进行变量的问题。
可修改性战术
局部化修改
-
维持语义的一致性
语义一致性指的是模块中责任之间的关系。目标是确保所有这些责任都能够协同工作，不需要过多地依赖其他模块。该目标是通过选择具有语义一致性的责任来实现的。耦合和内聚是度量语义一致性的尝试。其中一个子战术就是”抽象通用服务“。通过专门的模块提供通用服务通常被视作支持重用。这是正确的，但抽象通用服务也支持可修改性。如果已经抽象出了通用服务，那么，对这些通用服务的修改只需要进行一次，而不需要在使用这些服务的每个模块中都进行修改。此外，对使用这些服务的模块的修改不会影响其他的用户。因此，该战术不仅支持局部化修改，而且还能够防止连锁反应。抽象通用服务的示例就是应用框架的使用和其它中间件软件的使用。 -
预期期望的变更
考虑所预想的变更的集合提供了一个评估特定的责任分配的方法。基本的问题就是”对于每次变更，所建议的分解是否限定了为完成变量所需要修改的模块集合？“一个相关的问题是”根本不同的变更会影响相同的模块吗？“这与语义一致性有什么不同？根据语义一致性分配责任，假定期望的变更在语义上是一致的。预测期望变更战术并不关心模块责任的一致性，它所关心的是使变更的影响最小。在实际中很难单独使用该战术，因为不可能预期所有变更。基于此原因，我们通常结合一致性来使用该战术。 -
泛化该模块
使一个模块更通用能够使它根据输入计算更广泛的功能。 -
限制可能的选择
修改的范围可能非常大，因此可能会影响很多模块。限制可能的选择将会降低这些修改所造成的影响。
推迟绑定时间
我们的可修改性场景包括通过减少需要修改的模块的数量不能满足的两个元素--部署时间以及允许非开发人员进行修改。推迟绑定时间支持这两个场景，可以在各个时间把决策绑定到执行系统中。在运行时绑定意味着系统已经为该绑定做好了准备，并且完成了所有的测试和分配步骤。
-
运行时注册
支持即插即用操作，但需要管理注册的额外开销。例如，发布/订阅注册可以在运行时或载入时实现。 -
配置文件
目的是在启动时设置参数。 -
多态
允许方法调用的后期绑定。 -
组件更换
允许载入时间绑定。 -
遵守已定义的协议
允许独立进程的运行时绑定