設計模式與擴充性

 

獲得最大限度複用的關鍵在於對新需求和現有需求發生變化的預見性，要求系統具有良好的擴充性。一個擴充性不好的設計會導致維護代價的增加，甚至導致重構。

設計模式可以確保系統能以特定方式變化，提高擴充性，從而避免重構。每一個設計模式允許系統結構的某個方面的變化獨立於其他方面，這樣產生的系統對於某一特殊變化更加健壯。

 

以下一些導致重構的原因，以及解決這些問題的設計模式：

 

1、通過顯示地指定一個類來建立對象：

在建立對象時制定類名將使你受特定實現的約束，而不是特定介面的約束。這回使得未來的變化更加複雜。

應該間接地建立對象。

設計模式：Abstract Factory，Factory Method，Prototype；

 

2、對特殊操作的依賴：

當你為請求指定一個特殊的操作時，完成該請求的方式就固定下來了。

為了避免把請求代碼寫死，可以在編譯時間刻或運行時刻方便地改變響應請求的方法。

設計模式：Chain Of Resposibility，Command；

 

3、對硬體和軟體平台的依賴：

外部的作業系統介面和應用程式介面（API）在不同的軟硬體平台上是不同的。依賴於特定平台的軟體將很難移植到其他平台上，甚至很難跟上本地平台的更新。

實際系統時，限制其平台的相關性就很重要。

設計模式：Abstract Factory，Bridge；

 

4、對對象表示或實現的依賴：

知道對象怎樣表示、儲存、定位或者實現的客戶在對象發生變化時可能也需要變化。

對客戶隱藏這些資訊能阻止連鎖變化。

設計模式：Abstract Factory，Bridge，Memento，Proxy；

 

5、演算法依賴：

演算法在開發和複用時常常被擴充、最佳化和替換。依賴於某個特定演算法的對象在演算法發生變化時不得不變化。

因此，有可能發生變化的演算法應該被孤立起來。

設計模式：Builder，Iterator，Strategy，Template Method，Visitor；

 

6、高耦合：

高耦合的類很難獨立地被複用，因為它們是相互依賴的。高耦合產生單塊的系統，要改變或刪除一個類，必須理解和改變其他許多類。這樣的系統是很難理解、維護、移植的米集體。

低耦合提高一個類被複用的可能，並提高系統的擴充性。設計模式使用抽象耦合和分層技術來提高系統的低耦合性。

設計模式：Abstract Factory，Command，Facade，Mediator，Observer，Chain Of Responsiblity；

 

7、通過產生子類來擴充功能：

通常很難通過定義子類來定製對象。每一個新類都有固定的實現開銷（初始化、終止處理等）。定義子類還需要對父類有深入的瞭解。如，重定義一個操作可能需要重定義其他動作。一個被重定義的操作可能需要調用繼承下來的操作。並且子類方法會導致類爆炸，因為即使對於一個簡單的擴充，也不得不引入許多新的子類。

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

設計模式：Bridge，Chain Of Responsiblity，Composite，Decorator，Observer，Strategy；

 

8、不能方便地對類進行修改：

有時，不得不改變一個難以修改的類。也許需要源碼而又沒有，或者可能對類的任何改變會要求修改許多已存在的其他子類。

設計模式提供這種請況下對類進行修改的方法。

設計模式：Adapter，Decorator，Visitor。

 

 

以上內容來源於對《設計模式：可複用物件導向軟體的基礎》一書內容的整理，因為筆者是個窮銀，沒錢買書，正好借人家的來看，看完又怕記不住，就整理到這裡一份筆記。