在正式介紹橋接模式之前，我先跟大家談談兩種常見文具的區別，它們是毛筆和蠟筆。假如我們需要大中小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等違反了“單一職責原則”，因為不止一個引起它們變化的原因，它們將影象檔案解析和畫素矩陣顯示這兩種完全不同的職責融合在一起，任意一個職責發生改變都需要修改它們，系統擴充套件困難。

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