在本系列的第一篇文章中,描述了如何通過設(shè)計模式來指導我們的程序重構(gòu)過程,并且著重介紹了設(shè)計模式意圖、動機的重要性。在本文中我們將繼續(xù)上篇文章進行討論,這次主要著重于設(shè)計模式的適用性,對于設(shè)計模式適用性的掌握有助于從另一個不同的方面來判斷一個設(shè)計模式是否真正適用于我們的實際問題,從而做出明智的選擇。 ![]() 在這個類圖中,我增加了幾條依賴線,即ErrorHandler是依賴于DbError和CommError的。此時我們可以看到:ErrorBase依賴于ErrorHandler,ErrorHandler依賴于ErrorBase的派生類(DbError和CommError),而ErrorBase的派生類又要依賴于ErrorBase本身。這就形成了一個循環(huán)的依賴過程,這樣的結(jié)果就是ErrorBase傳遞地依賴于它的所有派生類。 這種循環(huán)依賴關(guān)系會帶來嚴重的問題,一旦ErrorBase新增了一個派生類,那么ErrorHandler類必須要被修改,由于ErrorBase又依賴于ErrorHandler,那么依賴于ErrorBase的所有類都需要重新編譯。這就意味著ErrorBase的所有派生類以及所有這些派生類的使用者都要重新編譯,這種大規(guī)模的重新編譯在開發(fā)一個分布式系統(tǒng)時會導致非常大的工作量,因為要重新分布每一個重新編譯過的類,如果在重新分布時出現(xiàn)一些差錯(如:忘記替換一些類),就會導致微妙的錯誤,而且很不容易查找出來。 另外,在該模式中存在一個假設(shè),就是默認任意一個錯誤處理者要處理所有的錯誤類型,這個假設(shè)在某些情況下是不成立的,比如:如果對于LogicError我們不打算通知LOGSys進行處理會怎樣呢?我們不得不要寫一個處理該錯誤的空函數(shù)(當然你可以在ErrorHandler中寫一個缺省的實現(xiàn))。如果ErrorBase的類層次架構(gòu)越來越大,并且它們要求的處理方法也有很多的不同,就會導致ErrorHandler接口中的方法集龐大,并且任何一個ErrorBase的派生類的改變,都會導致大規(guī)模的重新編譯(甚至是毫無關(guān)系的類也要重新編譯),重新分布,如果這種改變比較頻繁,結(jié)果當然是無法忍受的。 3、問題分析 上述的問題描述暴露了visitor模式的一些使用限制,即它僅僅適用于哪些受訪問的類層次架構(gòu)比較固定的情況,導致這樣的原因可以使用一個著名的面向?qū)ο笤O(shè)計原則來解釋,這個原則就是:DIP(Dependence Inversion Principle),這個原則的核心含義是:高層模塊不應該直接依賴于低層模塊,所有的模塊都要依賴于抽象。也就是說:容易變化的東西一定要依賴于不容易變化的東西,因為抽象的東西最不容易變化,具體的東西容易變化,所以具體應該依賴于抽象。而在visitor模式中,ErrorHandler依賴于ErrorBase的所有的具體的派生類,并且如果這些派生類容易變化的話,就會導致不能接受的結(jié)果。 通過上面的分析,可以看出打斷這個循環(huán)依賴的環(huán)是克服visitor模式適用范圍限制的關(guān)鍵。 4、解決方案 在上述的循環(huán)依賴關(guān)系中,有兩段依賴關(guān)系是無法打斷的,一段是ErrorBase的所有派生類對于ErrorBase的依賴,一段是ErrorBase對于ErrorHandler的依賴,并且這兩段依賴關(guān)系也是符合DIP的,那么對于僅剩的一段依賴關(guān)系我們是必須要打斷的了,這段關(guān)系就是,ErrorHandler對于ErrorBase所有派生類的依賴,并且這段關(guān)系也是違反DIP的。如果我們不讓ErrorHandler知道ErrorBase的派生類,那么怎樣才能夠針對每一個具體的ErrorBase的派生類進行相應的處理呢? 面向?qū)ο蟠髱烺obert C. Martin給出了一個優(yōu)雅的解決方案,他所采用的技巧是OO方法所建議避免使用的,RTTI(運行時類型鑒別)。可見如果RTTI運用的得當,一樣可以得到很好的設(shè)計方案,并且還能夠克服一些OO中多態(tài)的方法解決不了的問題(當然如果使用多態(tài)能夠解決的問題,推薦還是使用多態(tài)的方法進行解決)。讓我們先看看這個解決方案的類圖: ![]() 通過上圖可以看出,ErrorHandler中沒有任何方法了,已經(jīng)退化為一個空的接口,所以也就不可能再依賴于任何ErrorBase的派生類了。和visitor模式不同,這個方案中針對每一個特定的ErrorBase的派生類定義一個相應的處理接口,在每個派生類的handle方法實現(xiàn)中,運用RTTI技術(shù)進行相應的類型轉(zhuǎn)換(把ErrorHandler轉(zhuǎn)換為自己對應的錯誤處理接口,比如:在DbError的handle方法中,就把ErrorHandler轉(zhuǎn)換為DbErrorHandler。Java在這方面做得不錯,可以進行比較安全的類型轉(zhuǎn)換),想要處理該錯誤的實體不僅要實現(xiàn)ErrorHandler接口,而且還要實現(xiàn)相應的針對具體錯誤類的處理接口,比如:GUISys就實現(xiàn)了三個接口(ErrorHandler、DBErrorHandler以及CommErrorHandler),從而也就實現(xiàn)了對DbError和CommError的處理。 |
溫馨提示:喜歡本站的話,請收藏一下本站!