C#設計模式(8)——橋接模式(Bridge Pattern)

發表於2014-10-07

一、引言

這裡以電視遙控器的一個例子來引出橋接模式解決的問題,首先,我們每個牌子的電視機都有一個遙控器,此時我們能想到的一個設計是——把遙控器做為一個抽象類,抽象類中提供遙控器的所有實現,其他具體電視品牌的遙控器都繼承這個抽象類,具體設計類圖如下:

這樣的實現使得每部不同型號的電視都有自己遙控器實現,這樣的設計對於電視機的改變可以很好地應對,只需要新增一個派生類就搞定了,但隨著時間的推移,使用者需要改變遙控器的功能,如:使用者可能後面需要對遙控器新增返回上一個臺等功能時,此時上面的設計就需要修改抽象類RemoteControl的提供的介面了,此時可能只需要向抽象類中新增一個方法就可以解決了,但是這樣帶來的問題是我們改變了抽象的實現,如果使用者需要同時改變電視機品型號和遙控器功能時,上面的設計就會導致相當大的修改,顯然這樣的設計並不是好的設計。然而使用橋接模式可以很好地解決這個問題,下面讓我具體看看橋接模式是如何實現的。

二、橋接模式的詳細介紹

2.1 定義

橋接模式即將抽象部分與實現部分脫耦,使它們可以獨立變化。對於上面的問題中,抽象化也就是RemoteControl類,實現部分也就是On()、Off()、NextChannel()等這樣的方法(即遙控器的實現),上面的設計中,抽象化和實現部分在一起,橋接模式的目的就是使兩者分離,根據物件導向的封裝變化的原則,我們可以把實現部分的變化(也就是遙控器功能的變化)封裝到另外一個類中,這樣的一個思路也就是橋接模式的實現,大家可以對照橋接模式的實現程式碼來解決我們的分析思路。

2.2 橋接模式實現

上面定義部分已經給出了我們橋接模式的目的以及實現思路了,下面讓我們具體看看橋接模式是如何解決引言部分設計的不足。

抽象化部分的程式碼:

遙控器的實現方法部分程式碼,即實現化部分程式碼,此時我們用另外一個抽象類TV封裝了遙控器功能的變化,具體實現交給具體型號電視機去完成:

採用橋接模式的客戶端呼叫程式碼:

上面橋接模式的實現中,遙控器的功能實現方法不在遙控器抽象類中去實現了,而是把實現部分用來另一個電視機類去封裝它,然而遙控器中只包含電視機類的一個引用,同時這樣的設計也非常符合現實生活中的情況(我認為的現實生活中遙控器的實現——遙控器中並不包含換臺,開啟電視機這樣的功能的實現,遙控器只是包含了電視機上這些功能的引用,然後紅外線去找到電視機上對應功能的的實現)。通過橋接模式,我們把抽象化和實現化部分分離開了,這樣就可以很好應對這兩方面的變化了。

2.3 橋接模式的類圖

看完橋接模式的實現後,為了幫助大家理清對橋接模式中類之間關係,這裡給出橋接模式的類圖結構:

三、橋接模式的優缺點

介紹完橋接模式,讓我們看看橋接模式具體哪些優缺點。

優點:

把抽象介面與其實現解耦。

抽象和實現可以獨立擴充套件,不會影響到對方。

實現細節對客戶透明,對用於隱藏了具體實現細節。

缺點: 增加了系統的複雜度

四、使用場景

我們再來看看橋接模式的使用場景,在以下情況下應當使用橋接模式:

  1. 如果一個系統需要在構件的抽象化角色和具體化角色之間新增更多的靈活性,避免在兩個層次之間建立靜態的聯絡。
  2. 設計要求實現化角色的任何改變不應當影響客戶端,或者實現化角色的改變對客戶端是完全透明的。
  3. 需要跨越多個平臺的圖形和視窗系統上。
  4. 一個類存在兩個獨立變化的維度,且兩個維度都需要進行擴充套件。

五、一個實際應用橋接模式的例子

橋接模式也經常用於具體的系統開發中,對於三層架構中就應用了橋接模式,三層架構中的業務邏輯層BLL中通過橋接模式與資料操作層解耦(DAL),其實現方式就是在BLL層中引用了DAL層中一個引用。這樣資料操作的實現可以在不改變客戶端程式碼的情況下動態進行更換,下面看一個簡單的示例程式碼:

六、總結

到這裡,橋接模式的介紹就介紹,橋接模式實現了抽象化與實現化的解耦,使它們相互獨立互不影響到對方

相關文章