# 處理多維度變化——橋接模式（一） 在正式介紹橋接模式之前，我先跟大家談談兩種常見文具的區別，它們是毛筆和蠟筆。假如我們需要大中小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等違反了“單一職責原則”，因為不止一個引起它們變化的原因，它們將圖像文件解析和像素矩陣顯示這兩種完全不同的職責融合在一起，任意一個職責發生改變都需要修改它們，系統擴展困難。 如何改進？我們的方案是將圖像文件格式（對應圖像格式的解析）與操作系統（對應像素矩陣的顯示）兩個維度分離，使得它們可以獨立變化，增加新的圖像文件格式或者操作系統時都對另一個維度不造成任何影響。看到這里，大家可能會問，到底如何在軟件中實現將兩個維度分離呢？不用著急，本章我將為大家詳細介紹一種用于處理多維度變化的設計模式——橋接模式。