設計模式之橋接模式(Bridge)
1.引言
一位哲學家說“你永遠也看不到一條一模一樣的河”,不考慮哲學上的對錯,光是從變化的角度看,的確是這樣,因為盡管一條小河,在空間上沒有發生變化,但在時間坐標上已經發生了改變,世上萬物都在做著這樣的變化,但是你把一塊石頭放在你的魚缸里面,幾天后,你會發現它還是那塊石頭,這說明事物盡管都有向多個維度變化的特性,但是有些事物是相對比較穩定的,而有些事物多維度變化確實比較激勵的。我們用繼承(inherit)解決了變化不穩定的事物的擴展問題,如何利用面向對象的技術來使得事物能夠輕松的沿著多個方向進行變化,實現起來又不是很復雜呢?這就要使用Bridge模式。
2)意圖
使抽象部分和實現部分分離,使他們都能夠獨立的變化(GOF)
采用繼承的情況下,具體實現依賴于抽象定義,抽象定義被看作是相對穩定的。而對于像多個維度變化激烈的對象來說 ,抽象定義也是不穩定的。這時候,如果想盡可能付出小的代價,獲得最大的擴展,采用橋接模式是一個好的主意
3)結構圖
4)以坦克大戰中的坦克為例,說明橋接模式的優點
實例代碼為:
Abstraction
Implentor
RefinedAbstractuib
ConcreteImplementor
類關系圖為
運行結果:
源代碼:/Files/jillzhang/BridgeStudy.rar
總結:
1。Bridge模式使用“對象間的組合關系”解耦了抽象和實現之間固有的綁定關系,使得抽象和實現可以沿著各自的維度來變化。
一位哲學家說“你永遠也看不到一條一模一樣的河”,不考慮哲學上的對錯,光是從變化的角度看,的確是這樣,因為盡管一條小河,在空間上沒有發生變化,但在時間坐標上已經發生了改變,世上萬物都在做著這樣的變化,但是你把一塊石頭放在你的魚缸里面,幾天后,你會發現它還是那塊石頭,這說明事物盡管都有向多個維度變化的特性,但是有些事物是相對比較穩定的,而有些事物多維度變化確實比較激勵的。我們用繼承(inherit)解決了變化不穩定的事物的擴展問題,如何利用面向對象的技術來使得事物能夠輕松的沿著多個方向進行變化,實現起來又不是很復雜呢?這就要使用Bridge模式。
2)意圖
使抽象部分和實現部分分離,使他們都能夠獨立的變化(GOF)
采用繼承的情況下,具體實現依賴于抽象定義,抽象定義被看作是相對穩定的。而對于像多個維度變化激烈的對象來說 ,抽象定義也是不穩定的。這時候,如果想盡可能付出小的代價,獲得最大的擴展,采用橋接模式是一個好的主意
3)結構圖
4)以坦克大戰中的坦克為例,說明橋接模式的優點
實例代碼為:
運行結果:
源代碼:/Files/jillzhang/BridgeStudy.rar
總結:
1。Bridge模式使用“對象間的組合關系”解耦了抽象和實現之間固有的綁定關系,使得抽象和實現可以沿著各自的維度來變化。
2.所謂抽象和實現沿著各自維度的變化,即“子類化”它們,得到各個子類之后,便可以任意它們,從而獲得不同平臺上的不同型號。
3.Bridge模式有時候類似于多繼承方案,但是多繼承方案往往違背了類的單一職責原則(即一個類只有一個變化的原因),復用性比較差。Bridge模式是比多繼承方案更好的解決方法。
4.Bridge模式的應用一般在“兩個非常強的變化維度”,有時候即使有兩個變化的維度,但是某個方向的變化維度并不劇烈——換言之兩個變化不會導致縱橫交錯的結果,并不一定要使用Bridge模式。
適用性
在以下的情況下應當使用橋梁模式:
1.如果一個系統需要在構件的抽象化角色和具體化角色之間增加更多的靈活性,避免在兩個層次之間建立靜態的聯系。
2.設計要求實現化角色的任何改變不應當影響客戶端,或者說實現化角色的改變對客戶端是完全透明的。
3.一個構件有多于一個的抽象化角色和實現化角色,系統需要它們之間進行動態耦合。
4.雖然在系統中使用繼承是沒有問題的,但是由于抽象化角色和具體化角色需要獨立變化,設計要求需要獨立管理這兩者。
Bridge模式是一個非常有用的模式,也非常復雜,它很好的符合了開放-封閉原則和優先使用對象,而不是繼承這兩個面向對象原則。
關于橋接模式更好,更詳細的介紹請訪問.NET設計模式(9):橋接模式(Bridge Pattern)
作者:jillzhang
出處:http://jillzhang.cnblogs.com/
本文版權歸作者和博客園共有,歡迎轉載,但未經作者同意必須保留此段聲明,且在文章頁面明顯位置給出原文連接,否則保留追究法律責任的權利。
出處:http://jillzhang.cnblogs.com/
本文版權歸作者和博客園共有,歡迎轉載,但未經作者同意必須保留此段聲明,且在文章頁面明顯位置給出原文連接,否則保留追究法律責任的權利。





}
浙公網安備 33010602011771號