致使從新設計的緣由和解決之道

設計模式能夠確保系統能以特定方式變化，從而幫助你避免從新設計系統。每個設計 模式容許系統結構的某個方面的變化獨立於其餘方面，這樣產生的系統對於某一種特殊變化 將更健壯。

下面闡述了一些致使從新設計的通常緣由，以及解決這些問題的設計模式:

1) 經過顯式地指定一個類來建立對象 在建立對象時指定類名將使你受特定實現的約束 而不是特定接口的約束。這會使將來的變化更復雜。要避免這種狀況，應該間接地建立對象。

設計模式:抽象工廠A b s t r a c t F a c t o r y，工廠方法F a c t o r y M e t h o d，原型P r o t o t y p e。

2) 對特殊操做的依賴 當你爲請求指定一個特殊的操做時，完成該請求的方式就固定下 來了。爲避免把請求代碼寫死，你將能夠在編譯時刻或運行時刻很方便地改變響應請求的方 法。

設計模式: 職責鏈 C h a i n o f R e s p o s i b i l i t y ，命令模式 C o m m a n d 。
3) 對 硬 件 和 軟 件 平 臺 的 依 賴 外 部 的 操 做 系 統 接 口 和 應 用 編 程 接 口 ( A P I ) 在 不 同 的 軟 硬 件 平臺上是不一樣的。依賴於特定平臺的軟件將很難移植到其餘平臺上，甚至都很難跟上本地平 臺的更新。因此設計系統時限制其平臺相關性就很重要了。

設計模式: 抽象工廠 A b s t r a c t F a c t o r y ，橋接 B r i d g e 。

4) 對對象表示或實現的依賴 知道對象怎樣表示、保存、定位或實現的客戶在對象發生 變化時可能也須要變化。對客戶隱藏這些信息能阻止連鎖變化。

設計模式: 抽象工廠 A b s t r a c t F a c t o r y， 橋接B r i d g e ，備忘錄M e m e n t o，代理 P r o x y

5) 算法依賴 算法在開發和複用時經常被擴展、優化和替代。依賴於某個特定算法的對 象在算法發生變化時不得不變化。所以有可能發生變化的算法應該被孤立起來。

設計模式: 建立者 B u i l d e r，迭代器I t e r a t o r，策略S t r a t e g y，模版方法 T e m p l a t e M e t h o d ，訪問者 V i s i t o r 

6) 緊耦合 緊耦合的類很難獨立地被複用，由於它們是互相依賴的。緊耦合產生單塊的 系統，要改變或刪掉一個類，你必須理解和改變其餘許多類。這樣的系統是一個很難學習、 移植和維護的密集體。

鬆散耦合提升了一個類自己被複用的可能性，而且系統更易於學習、移植、修改和擴展。 設計模式使用抽象耦合和分層技術來提升系統的鬆散耦合性。

設計模式: 抽象工廠 A b s t r a c t F a c t o r y ，命令模式 C o m m a n d ，外觀模式 F a c a d e ，中介者 M e d i a t o r，觀察者 Observer，職責鏈Chain of Responsibility。

7) 經過生成子類來擴充功能 一般很難經過定義子類來定製對象。每個新類都有固定 的實現開銷(初始化、終止處理等)。定義子類還須要對父類有深刻的瞭解。如，重定義一個操 做可能須要重定義其餘操做。一個被重定義的操做可能須要調用繼承下來的操做。而且子類 方法會致使類爆炸，由於即便對於一個簡單的擴充，你也不得不引入許多新的子類。

通常的對象組合技術和具體的委託技術，是繼承以外組合對象行爲的另外一種靈活方法。 新的功能能夠經過以新的方式組合已有對象，而不是經過定義已存在類的子類的方式加到應 用中去。另外一方面，過多使用對象組合會使設計難於理解。許多設計模式產生的設計中，你 能夠定義一個子類，且將它的實例和已存在實例進行組合來引入定製的功能。

設計模式: 橋接B r i d g e，職責鏈 C h a i n o f R e s p o n s i b i l i t y，組合C o m p o s i t e，裝飾者 D e c o r a t o r，觀察者 O b s e r v e r ，策略 S t r a t e g y。

8) 不能方便地對類進行修改 有時你不得不改變一個難以修改的類。也許你須要源代碼 而又沒有 (對於商業類庫就有這種狀況 )，或者可能對類的任何改變會要求修改許多已存在的其 他子類。設計模式提供在這些狀況下對類進行修改的方法。

設計模式: 適配器A d a p t e r， 裝飾者D e c o r a t o r ，訪問者 Vi s i t o r 。