處理多維度變化——橋接模式（一）

       在正式介紹橋接模式之前，我先跟大家談談兩種常見文具的區別，它們是毛筆和蠟筆。假如我們需要大中小3種型號的畫筆，能夠繪製12種不同的顏色，如果使用蠟筆，需要準備3×12
= 36支，但如果使用毛筆的話，只需要提供3種型號的毛筆，外加12個顏料盒即可，涉及到的對象個數僅為
3 + 12 = 15，遠小於36，卻能實現與36支蠟筆同樣的功能。如果增加一種新型號的畫筆，並且也需要具有12種顏色，對應的蠟筆需增加12支，而毛筆只需增加一支。為什麼會這樣呢？通過分析我們可以得知：在蠟筆中，顏色和型號兩個不同的變化維度（即兩個不同的變化原因）融合在一起，無論是對顏色進行擴充還是對型號進行擴充都勢必會影響另一個維度；但在毛筆中，顏色和型號實現了分離，增加新的顏色或者型號對另一方都沒有任何影響。如果使用軟體工程中的術語，我們可以認為在蠟筆中顏色和型號之間存在較強的耦合性，而毛筆很好地將二者解耦，使用起來非常靈活，擴充也更為方便。在軟體開發中，我們也提供了一種設計模式來處理與畫筆類似的具有多變化維度情況，即本章將要介紹的橋接模式。

10.1 跨平台映像瀏覽系統

Sunny軟體公司欲開發一個跨平台映像瀏覽系統，要求該系統能夠顯示BMP、JPG、GIF、PNG等多種格式的檔案，並且能夠在Windows、Linux、Unix等多個作業系統上運行。系統首先將各種格式的檔案解析為像素矩陣(Matrix)，然後將像素矩陣顯示在螢幕上，在不同的作業系統中可以調用不同的繪製函數來繪製像素矩陣。系統需具有較好的擴充性以支援新的檔案格式和作業系統。

      Sunny軟體公司的開發人員針對上述要求，提出了一個初始設計方案，其基本結構10-1所示：

        在圖10-1的初始設計方案中，使用了一種多層繼承結構，Image是抽象父類，而每一種類型的映像類，如BMPImage、JPGImage等作為其直接子類，不同的影像檔格式具有不同的解析方法，可以得到不同的像素矩陣；由於每一種映像又需要在不同的作業系統中顯示，不同的作業系統在螢幕上顯示像素矩陣有所差異，因此需要為不同的映像類再提供一組在不同作業系統顯示的子類，如為BMPImage提供三個子類BMPWindowsImp、BMPLinuxImp和BMPUnixImp，分別用於在Windows、Linux和Unix三個不同的作業系統下顯示映像。

      
我們現在對該設計方案進行分析，發現存在如下兩個主要問題：

       (1)由於採用了多層繼承結構，導致系統中類的個數急劇增加，圖10-1中，在各種映像的作業系統實現層提供了12個具體類，加上各級抽象層的類，系統中類的總個數達到了17個，在該設計方案中，具體層的類的個數
= 所支援的影像檔格式數×所支援的作業系統數。

       (2)系統擴充麻煩，由於每一個具體類既包含影像檔格式資訊，又包含作業系統資訊，因此無論是增加新的影像檔格式還是增加新的作業系統，都需要增加大量的具體類，例如在圖10-1中增加一種新的影像檔格式TIF，則需要增加3個具體類來實現該格式映像在3種不同作業系統的顯示；如果增加一個新的作業系統Mac
OS，為了在該作業系統下能夠顯示各種類型的映像，需要增加4個具體類。這將導致系統變得非常龐大，增加運行和維護開銷。

      
如何解決這兩個問題？我們通過分析可得知，該系統存在兩個獨立變更維度：影像檔格式和作業系統，10-2所示：

        在圖10-2中，如何將各種不同類型的影像檔解析為像素矩陣與影像檔格式本身相關，而如何在螢幕上顯示像素矩陣則僅與作業系統相關。正因為圖10-1所示結構將這兩種職責集中在一個類中，導致系統擴充麻煩，從類的設計角度分析，具體類BMPWindowsImp、BMPLinuxImp和BMPUnixImp等違反了“單一職責原則”，因為不止一個引起它們變化的原因，它們將影像檔解析和像素矩陣顯示這兩種完全不同的職責融合在一起，任意一個職責發生改變都需要修改它們，系統擴充困難。

        如何改進？我們的方案是將影像檔格式（對應映像格式的解析）與作業系統（對應像素矩陣的顯示）兩個維度分離，使得它們可以獨立變化，增加新的影像檔格式或者作業系統時都對另一個維度不造成任何影響。看到這裡，大家可能會問，到底如何在軟體中實現將兩個維度分離呢？不用著急，本章我將為大家詳細介紹一種用於處理多維度變化的設計模式——橋接模式。

【作者：劉偉http://blog.csdn.net/lovelion】