如果程序中的一處改動導致一系列模塊的改動，那麼程序的設計就比較的僵化。重構就是必要的。理想的狀況是隻需要添加新的代碼而不需要改動現有的，或者極少。現在有一些策略可以幫助我們接近這個美好的目標。
關鍵是抽象，如果模塊依賴與一個固定的抽象，那麼其對未來的改變可以是關閉的。在設計模式中，stratege 和template method模式可以做到這一點。但是這裏的問題只有決定了對什麼或者說怎麼樣抽象，一邊應用我們的現有模式呢？顯然，未來的需求是很難預測的，想要一種對所有的改變都關閉的抽象似乎是不大現實的。所以我們必須要對模塊應該對那種變化關閉進行選擇。一般我們依據經驗或者請教領域專家可以做出取捨，一般選擇就是那些最有可能會發生的變化，進而進行貼切的抽象。不成熟的抽象--過度設計--往往會帶來額外的成本，而收益往往很少，當然你的目的是完美的設計，而不及成本也未嘗不可。
但是，變化時不可避免的。隨之而來的問題就是如何能對變化更早，更有效地做出反應呢？一是我們希望改變儘可能早的來到，而不是等到交給客戶的時候才發現；在一個就是碰到某種新的改變時，設計/抽象可能需要重構，這是必要的代價，但是重構後的抽象必須要能夠屏蔽掉以後同種類型的改變，也就是”只受一次愚弄”。
敏捷開發有一系列的指導原則幫助我們只受一次愚弄（至於如何進行抽象則是設計模式的事了）：
1）首先編寫測試，使系統是一個可測試的系統。這樣可以更好的應對變化
2）使用很短的迭代開發週期
3）再加入基礎結構以前就進行特性開發，並且經常將這些特性展現給我們的“客戶”
4）首先開發最重要的特性
5）儘早的、經常性的發佈軟件。這樣我們可以更頻繁地把軟件呈現在“客戶”面前。
OCP在很多的方面都是面向對像設計的核心所在。