獲得最大限度複用的關鍵在於對新需求和已有需求發生變化時的預見性，要求我們的系統設計能夠相應地改進。下面闡述一些導致重新設計的一般原因，以及解決這些問題的設計模式。
（1）、通過顯式地指定一個類來創建對象 。 在創建對像是指定類名將使你受特定實現的約束而不是特定接口的約束，這會使未來的變化更加複雜，要避免這種情況，應該間接地創建對像，此時考慮： Abstract Factory 、Factory Method 、Prototype
（2）、對特殊操作的依賴。當你爲請求指定一個特殊地操作時，完成該請求的方式就固定下來了，爲了避免把請求代碼寫死，可以在編譯或運行時刻很方便地改變響應請求的方式。此時考慮： Chain of Responsibility ， Command
（3）、對硬件和軟件平臺的依賴。外部的OS接口和應用編程接口（API）在不同的軟硬件平臺上是不同的，依賴於特定平臺的軟件將很難移稙到其它平臺上，甚至很難跟上本地平臺的更新，所以設計系統時限制其平臺相關性就很重要了。此時考慮： Abstract Factory , Bridge
（4）、對對像表示或實現的依賴。 知道對像怎樣表示、保存、定位或實現的客戶在對像發生變化時可能也需要變化，阻止連鎖變化的辦法就是對客戶隱藏這些變化。此時考慮：Abstract Factory 、Bridge、Memento、Proxy
（5）、算法依賴。算法在開發和複用時常常被擴展、優化和替代。依賴於某個特定算法的對像在算法發生變變化時不得不變化。因此有可能發生變化的算法應該被孤立起來。此時考慮：Builder、Iterator、Strategy 、Template Method、Visitor
（6）、緊耦合。 緊耦合的類很難獨立地被複用，因爲它們是互相依賴的。緊耦合產生單快的系統，要改變或刪掉一個類，必須理解和改變其它許多類。這樣的系統是一個很難學習、移稙和維護的密集體。
鬆散耦合提高了一個類本身被複用的可能性，並且系統更易於學習、移稙、修改和擴展。設計模式使用抽象耦合和分層技術來提高系統的鬆散耦合性。此時考慮：Abstract Factory、Command、Façade、Mediator、Observer，Chain of Responsibility
（7）、通過擴充子類來擴充功能。 通常很難通過定製子類來定製對像，每一個新類都有固定的實現開銷（初始化，終止處理等），定義子類還需要對父類有深入的瞭解，如，重定義一個操作可能需要重定義其它操作，並且子類方法會導致類爆炸，因爲即使對於一個簡單的擴充，你也不得不引入許多新的子類。
一般的對像組合技術和委託技術，是繼承之外組合對像行爲的另一種靈活的方法，新的功能可以通過新的方式組合已有對像，而不是通過定義已經存在的類的子類的方式加到應用中去，另一方面，過多使用對像組合會使設計難於理解。許多設計模式產生的設計中，你可以定義一個子類，且將它的實例和已存在的實例進行組合來引入定製的功能。設計模式：Bridge，Chain of Responsibility，Composite，Decorator，Observer，Strategy。
（8）、不能方便地對類進行修改。 有時候不得不改變一個難以修改的類，也許你需要而已沒有（商業類庫），或許可能對類的任何改變會要求修改許多已存在的其它子類，設計模式提供在這些情況下對類進行修改的方法。Adapter，Decorator，Visitor