使用設計模式改善程序結構（2）

	China


搜索幫助

IBM 主頁 | 產品與服務 | 支持與下載 | 個性化服務

IBM : developerWorks 中國網站 : Java : 所有的文章


	使用設計模式改善程序結構（二）

內容：

鄧輝，孫鳴 ([email protected])
軟件工程師

在本系列的第一篇文章中，描述瞭如何通過設計模式來指導我們的程序重構過程，並且着重介紹了設計模式意圖、動機的重要性。在本文中我們將繼續上篇文章進行討論，這次主要着重於設計模式的適用性，對於設計模式適用性的掌握有助於從另一個不同的方面來判斷一個設計模式是否真正適用於我們的實際問題，從而做出明智的選擇。

1、回顧

在上一篇文章中，我們給出了一個使用設計模式來改善程序結構的例子，着重介紹了設計模式的意圖、動機在我們程序重構過程中的指導作用。

現在，我們將關注設計模式的另一個重要方面：設計模式的適用性。解決同一個問題一般會有多種方案或者模式，但是這些模式所關注的是同一個問題的不同方面，解決不同的需求，有各自的優點和限制，各有各的解決之道。這就要求我們在選擇設計模式時，對我們自己的問題有很好的理解：我們的需求是什麼，我們要克服什麼樣的限制，我們要獲得什麼樣的特性等等。然後，可以看看我們想使用的解決問題的設計模式是否適用於我們的問題，如果不適用，是否可以使用其他的模式來彌補，是否可以對這個設計模式進行改進使它符合我們的要求。

本文下面的部分，我們將對上一篇文章中的最終解決方案進行進一步的分析，來看看它到底滿足了我們什麼樣的需求，又暴露了什麼樣的不足，最後我們會給出一個更爲符合要求的解決方案。

2、問題描述

在上一篇文章中，我們對一個網管系統中的錯誤處理部分的代碼進行了重構，最終使用了一個visitor設計模式解決了我們的問題。細心的讀者肯定會發現，這個最終方案一樣存在着一個問題：如果錯誤的類型不是固定不變的，而是隨着系統的進展不斷增加的，會有什麼結果呢？讓我們首先來看看上一篇文章中最終的類圖：

在這個類圖中，我增加了幾條依賴線，即ErrorHandler是依賴於DbError和CommError的。此時我們可以看到：ErrorBase依賴於ErrorHandler，ErrorHandler依賴於ErrorBase的派生類（DbError和CommError），而ErrorBase的派生類又要依賴於ErrorBase本身。這就形成了一個循環的依賴過程，這樣的結果就是ErrorBase傳遞地依賴於它的所有派生類。

這種循環依賴關係會帶來嚴重的問題，一旦ErrorBase新增了一個派生類，那麼ErrorHandler類必須要被修改，由於ErrorBase又依賴於ErrorHandler，那麼依賴於ErrorBase的所有類都需要重新編譯。這就意味着ErrorBase的所有派生類以及所有這些派生類的使用者都要重新編譯，這種大規模的重新編譯在開發一個分佈式系統時會導致非常大的工作量，因爲要重新分佈每一個重新編譯過的類，如果在重新分佈時出現一些差錯（如：忘記替換一些類），就會導致微妙的錯誤，而且很不容易查找出來。

另外，在該模式中存在一個假設，就是默認任意一個錯誤處理者要處理所有的錯誤類型，這個假設在某些情況下是不成立的，比如：如果對於LogicError我們不打算通知LOGSys進行處理會怎樣呢？我們不得不要寫一個處理該錯誤的空函數（當然你可以在ErrorHandler中寫一個缺省的實現）。如果ErrorBase的類層次架構越來越大，並且它們要求的處理方法也有很多的不同，就會導致ErrorHandler接口中的方法集龐大，並且任何一個ErrorBase的派生類的改變，都會導致大規模的重新編譯（甚至是毫無關係的類也要重新編譯），重新分佈，如果這種改變比較頻繁，結果當然是無法忍受的。

3、問題分析

上述的問題描述暴露了visitor模式的一些使用限制，即它僅僅適用於哪些受訪問的類層次架構比較固定的情況，導致這樣的原因可以使用一個著名的面向對象設計原則來解釋，這個原則就是：DIP（Dependence Inversion Principle），這個原則的核心含義是：高層模塊不應該直接依賴於低層模塊，所有的模塊都要依賴於抽象。也就是說：容易變化的東西一定要依賴於不容易變化的東西，因爲抽象的東西最不容易變化，具體的東西容易變化，所以具體應該依賴於抽象。而在visitor模式中，ErrorHandler依賴於ErrorBase的所有的具體的派生類，並且如果這些派生類容易變化的話，就會導致不能接受的結果。

通過上面的分析，可以看出打斷這個循環依賴的環是克服visitor模式適用範圍限制的關鍵。

4、解決方案

在上述的循環依賴關係中，有兩段依賴關係是無法打斷的，一段是ErrorBase的所有派生類對於ErrorBase的依賴，一段是ErrorBase對於ErrorHandler的依賴，並且這兩段依賴關係也是符合DIP的，那麼對於僅剩的一段依賴關係我們是必須要打斷的了，這段關係就是，ErrorHandler對於ErrorBase所有派生類的依賴，並且這段關係也是違反DIP的。如果我們不讓ErrorHandler知道ErrorBase的派生類，那麼怎樣才能夠針對每一個具體的ErrorBase的派生類進行相應的處理呢？

面向對象大師Robert C. Martin給出了一個優雅的解決方案，他所採用的技巧是OO方法所建議避免使用的，RTTI（運行時類型鑑別）。可見如果RTTI運用的得當，一樣可以得到很好的設計方案，並且還能夠克服一些OO中多態的方法解決不了的問題（當然如果使用多態能夠解決的問題，推薦還是使用多態的方法進行解決）。讓我們先看看這個解決方案的類圖：

通過上圖可以看出，ErrorHandler中沒有任何方法了，已經退化爲一個空的接口，所以也就不可能再依賴於任何ErrorBase的派生類了。和visitor模式不同，這個方案中針對每一個特定的ErrorBase的派生類定義一個相應的處理接口，在每個派生類的handle方法實現中，運用RTTI技術進行相應的類型轉換（把ErrorHandler轉換爲自己對應的錯誤處理接口，比如：在DbError的handle方法中，就把ErrorHandler轉換爲DbErrorHandler。Java在這方面做得不錯，可以進行比較安全的類型轉換），想要處理該錯誤的實體不僅要實現ErrorHandler接口，而且還要實現相應的針對具體錯誤類的處理接口，比如：GUISys就實現了三個接口（ErrorHandler、DBErrorHandler以及CommErrorHandler），從而也就實現了對DbError和CommError的處理。

這種方法打斷了類之間的循環依賴關係，使得增加新的錯誤類型變得容易，並且也避免了可能出現的大規模的重新編譯以及類的重新分佈。並且，你也可以有選擇地進行錯誤的處理，比如：如果GUISys不想處理DbError的話，很簡單，不要實現DbErrorHandler接口即可，使得程序的結構非常清晰。可見這個方案克服了原始的visitor設計模式的不足。

通過對比上下兩個類圖可以看出，下面的要比上面的複雜，這也是該方案的一個缺點。如果問題的規模不大，重新編譯以及重新分佈沒有多少工作量的話，還是可以使用原始的visitor模式的。僅僅當問題的規模擴大到visitor模式不能適用的地步時，可以考慮使用該方案。另外，由於改進的方案中使用了RTTI技術，會導致性能上的損失以及不可預測性，在使用時也要特別注意。

我們做如下的類比以便於更好地理解原始的visitor模式和改進後的方案。原始的visitor模式好像一個矩陣，在X方向上是一個個具體的錯誤類型，在Y方向上是一個個可以處理錯誤的實體，每一個交叉點上是具體的處理方法，矩陣中的每一個位置上都必須有一個處理方法。而改進後的方案象一個稀疏矩陣，僅僅在需要的位置上纔有具體的處理方法，從而減少了很多冗餘。

下面給出關鍵的代碼片斷：



interface ErrorBase
{
    public void handle(ErrorHandler handler);
}

class DBError implements ErrorBase
{
    public void handle(ErrorHandler handler) {
        try {
            DbErrorHandler dbHandler = (DbErrorHandler)handler;
            dbHandler.handle(this);
        }
        catch(ClassCastException e) {
        }
    }
}

class CommError implements ErrorBase
{
    public void handle(ErrorHandler handler) {
        try {
            CommErrorHandler commHandler = (CommErrorHandler)handler;
            commHandler.handle(this);
        }
        catch(ClassCastException e)/ {
        }
    }
}

interface ErrorHandler 
{
}

interface DbErrorHandler
{
    public void handle(DBrror dbError);
}

interface CommErrorHandler
{
    public void handle(CommError commError);
}

class GUISys implements ErrorHandler, DbErrorHandler, CommErrorHandler
{
    public void announceError(ErrorBase error) {
        error.handle(this);
    }

    public void handle(DBError dbError) {
 		/* 通知用戶界面進行有關數據庫錯誤的處理 */       
    }

    public void handle(CommError commError) {
    		/* 通知用戶界面進行有關通信錯誤的處理 */       
    }
}

class LogSys implements ErrorHandler, DbErrorHandler, CommErrorHandler
{
    public void announceError(ErrorBase error) {
        error.handle(this);
    }

    public void handle(DBError dbError) {
        		/* 通知日誌系統進行有關數據庫錯誤的處理 */       
    }

    public void handle(CommError commError) {
		/* 通知日誌系統進行有關通信錯誤的處理 */       
    }
}

5、結論

本文從另一個方面，設計模式的適用性，探討了在進行程序重構時該如何選擇重構的目標，以及如何對現有的設計模式進行改進使之符合我們的目標。本文的主要目的是想說明，在進行設計模式的選擇時，不僅要關注設計模式是解決什麼問題的，還要關注使用該設計模式解決問題時會受到什麼約束和限制。這樣就可以幫助你更好地理解問題，做出合理的取捨，或者你可以根據自己的需求對已有的設計模式進行修改使之滿足你的要求，如果你這樣做了，你就很可能創造出了一種新的設計模式。

參考文獻

[1] Design Patterns, Gamma, et. al., Addison Wesley
[2] Design Principles and Design Patterns，Robert C. Martin，www.objectmentor.com
[3] Refactoring To Patterns, Joshua Kerievsky, industriallogic.com
[4] The Visitor Family of Design Patterns，Robert C. Martin，www.objectmentor.com