（ 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