《Design patterns》讀書筆記

獲得最大限度複用的關鍵在于對新需求和已有需求發生變化時的預見性，要求我們的系統設計能夠相應地改進。下面闡述一些導緻重新設計的一般原因，以及解決這些問題的設計模式。

（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