如果程序中的一处改动导致一系列模块的改动，那么程序的设计就比较的僵化。重构就是必要的。理想的状况是只需要添加新的代码而不需要改动现有的，或者极少。现在有一些策略可以帮助我们接近这个美好的目标。
关键是抽象，如果模块依赖与一个固定的抽象，那么其对未来的改变可以是关闭的。在设计模式中，stratege 和template method模式可以做到这一点。但是这里的问题只有决定了对什么或者说怎么样抽象，一边应用我们的现有模式呢？显然，未来的需求是很难预测的，想要一种对所有的改变都关闭的抽象似乎是不大现实的。所以我们必须要对模块应该对那种变化关闭进行选择。一般我们依据经验或者请教领域专家可以做出取舍，一般选择就是那些最有可能会发生的变化，进而进行贴切的抽象。不成熟的抽象--过度设计--往往会带来额外的成本，而收益往往很少，当然你的目的是完美的设计，而不及成本也未尝不可。
但是，变化时不可避免的。随之而来的问题就是如何能对变化更早，更有效地做出反应呢？一是我们希望改变尽可能早的来到，而不是等到交给客户的时候才发现；在一个就是碰到某种新的改变时，设计/抽象可能需要重构，这是必要的代价，但是重构后的抽象必须要能够屏蔽掉以后同种类型的改变，也就是”只受一次愚弄”。
敏捷开发有一系列的指导原则帮助我们只受一次愚弄（至于如何进行抽象则是设计模式的事了）：
1）首先编写测试，使系统是一个可测试的系统。这样可以更好的应对变化
2）使用很短的迭代开发周期
3）再加入基础结构以前就进行特性开发，并且经常将这些特性展现给我们的“客户”
4）首先开发最重要的特性
5）尽早的、经常性的发布软件。这样我们可以更频繁地把软件呈现在“客户”面前。
OCP在很多的方面都是面向对像设计的核心所在。