处理多维度变化——桥接模式
本文轉載自 ：http://blog.csdn.net/lovelion/article/details/7464183
在正式介紹橋接模式之前，我先跟大家談談兩種常見文具的區別，它們是毛筆和蠟筆。假如我們需要大中小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等違反了“單一職責原則”，因為不止一個引起它們變化的原因，它們將圖像文件解析和像素矩陣顯示這兩種完全不同的職責融合在一起，任意一個職責發生改變都需要修改它們，系統擴展困難。
??????? 如何改進？我們的方案是將圖像文件格式（對應圖像格式的解析）與操作系統（對應像素矩陣的顯示）兩個維度分離，使得它們可以獨立變化，增加新的圖像文件格式或者操作系統時都對另一個維度不造成任何影響。看到這里，大家可能會問，到底如何在軟件中實現將兩個維度分離呢？不用著急，本章我將為大家詳細介紹一種用于處理多維度變化的設計模式——橋接模式。
10.2 橋接模式概述
??????? 橋接模式是一種很實用的結構型設計模式，如果軟件系統中某個類存在兩個獨立變化的維度，通過該模式可以將這兩個維度分離出來，使兩者可以獨立擴展，讓系統更加符合“單一職責原則”。與多層繼承方案不同，它將兩個獨立變化的維度設計為兩個獨立的繼承等級結構，并且在抽象層建立一個抽象關聯，該關聯關系類似一條連接兩個獨立繼承結構的橋，故名橋接模式。
??????? 橋接模式用一種巧妙的方式處理多層繼承存在的問題，用抽象關聯取代了傳統的多層繼承，將類之間的靜態繼承關系轉換為動態的對象組合關系，使得系統更加靈活，并易于擴展，同時有效控制了系統中類的個數。橋接定義如下：
| 橋接模式(Bridge Pattern)：將抽象部分與它的實現部分分離，使它們都可以獨立地變化。它是一種對象結構型模式，又稱為柄體(Handle and Body)模式或接口(Interface)模式。 |
??????? 橋接模式的結構與其名稱一樣，存在一條連接兩個繼承等級結構的橋，橋接模式結構如圖10-3所示：
??????? 在橋接模式結構圖中包含如下幾個角色：
●Abstraction（抽象類）：用于定義抽象類的接口，它一般是抽象類而不是接口，其中定義了一個Implementor（實現類接口）類型的對象并可以維護該對象，它與Implementor之間具有關聯關系，它既可以包含抽象業務方法，也可以包含具體業務方法。
●RefinedAbstraction（擴充抽象類）：擴充由Abstraction定義的接口，通常情況下它不再是抽象類而是具體類，它實現了在Abstraction中聲明的抽象業務方法，在RefinedAbstraction中可以調用在Implementor中定義的業務方法。
●Implementor（實現類接口）：定義實現類的接口，這個接口不一定要與Abstraction的接口完全一致，事實上這兩個接口可以完全不同，一般而言，Implementor接口僅提供基本操作，而Abstraction定義的接口可能會做更多更復雜的操作。Implementor接口對這些基本操作進行了聲明，而具體實現交給其子類。通過關聯關系，在Abstraction中不僅擁有自己的方法，還可以調用到Implementor中定義的方法，使用關聯關系來替代繼承關系。
●ConcreteImplementor（具體實現類）：具體實現Implementor接口，在不同的ConcreteImplementor中提供基本操作的不同實現，在程序運行時，ConcreteImplementor對象將替換其父類對象，提供給抽象類具體的業務操作方法。
??????? 橋接模式是一個非常有用的模式，在橋接模式中體現了很多面向對象設計原則的思想，包括“單一職責原則”、“開閉原則”、“合成復用原則”、“里氏代換原則”、“依賴倒轉原則”等。熟悉橋接模式有助于我們深入理解這些設計原則，也有助于我們形成正確的設計思想和培養良好的設計風格。
??????? 在使用橋接模式時，我們首先應該識別出一個類所具有的兩個獨立變化的維度，將它們設計為兩個獨立的繼承等級結構，為兩個維度都提供抽象層，并建立抽象耦合。通常情況下，我們將具有兩個獨立變化維度的類的一些普通業務方法和與之關系最密切的維度設計為“抽象類”層次結構（抽象部分），而將另一個維度設計為“實現類”層次結構（實現部分）。例如：對于毛筆而言，由于型號是其固有的維度，因此可以設計一個抽象的毛筆類，在該類中聲明并部分實現毛筆的業務方法，而將各種型號的毛筆作為其子類；顏色是毛筆的另一個維度，由于它與毛筆之間存在一種“設置”的關系，因此我們可以提供一個抽象的顏色接口，而將具體的顏色作為實現該接口的子類。在此，型號可認為是毛筆的抽象部分，而顏色是毛筆的實現部分，結構示意圖如圖10-4所示：
??????在圖10-4中，如果需要增加一種新型號的毛筆，只需擴展左側的“抽象部分”，增加一個新的擴充抽象類；如果需要增加一種新的顏色，只需擴展右側的“實現部分”，增加一個新的具體實現類。擴展非常方便，無須修改已有代碼，且不會導致類的數目增長過快。
????在具體編碼實現時，由于在橋接模式中存在兩個獨立變化的維度，為了使兩者之間耦合度降低，首先需要針對兩個不同的維度提取抽象類和實現類接口，并建立一個抽象關聯關系。對于“實現部分”維度，典型的實現類接口代碼如下所示：
[java]?view plaincopy??????? 在實現Implementor接口的子類中實現了在該接口中聲明的方法，用于定義與該維度相對應的一些具體方法。
??????? 對于另一“抽象部分”維度而言，其典型的抽象類代碼如下所示：
[java]?view plaincopy??????? 在抽象類Abstraction中定義了一個實現類接口類型的成員對象impl，再通過注入的方式給該對象賦值，一般將該對象的可見性定義為protected，以便在其子類中訪問Implementor的方法，其子類一般稱為擴充抽象類或細化抽象類(RefinedAbstraction)，典型的RefinedAbstraction類代碼如下所示：
[java]?view plaincopy????? 對于客戶端而言，可以針對兩個維度的抽象層編程，在程序運行時再動態確定兩個維度的子類，動態組合對象，將兩個獨立變化的維度完全解耦，以便能夠靈活地擴充任一維度而對另一維度不造成任何影響。
|
10.3? 完整解決方案
??????? 為了減少所需生成的子類數目，實現將操作系統和圖像文件格式兩個維度分離，使它們可以獨立改變，Sunny公司開發人員使用橋接模式來重構跨平臺圖像瀏覽系統的設計，其基本結構如圖10-5所示：
在圖10-5中，Image充當抽象類，其子類JPGImage、PNGImage、BMPImage和GIFImage充當擴充抽象類；ImageImp充當實現類接口，其子類WindowsImp、LinuxImp和UnixImp充當具體實現類。完整代碼如下所示： [java]?view plaincopy
??????? 為了讓系統具有更好的靈活性和可擴展性，我們引入了配置文件，將具體擴充抽象類和具體實現類類名都存儲在配置文件中，再通過反射生成對象，將生成的具體實現類對象注入到擴充抽象類對象中，其中，配置文件config.xml的代碼如下所示：
[html]?view plaincopy??????? 用于讀取配置文件config.xml并反射生成對象的XMLUtil類的代碼如下所示：
[java]?view plaincopy????????編寫如下客戶端測試代碼：
[java]?view plaincopy??????? 編譯并運行程序，輸出結果如下：
| 在Windows操作系統中顯示圖像：小龍女，格式為JPG。 |
??????? 如果需要更換圖像文件格式或者更換操作系統，只需修改配置文件即可，在實際使用時，可以通過分析圖像文件格式后綴名來確定具體的文件格式，在程序運行時獲取操作系統信息來確定操作系統類型，無須使用配置文件。當增加新的圖像文件格式或者操作系統時，原有系統無須做任何修改，只需增加一個對應的擴充抽象類或具體實現類即可，系統具有較好的可擴展性，完全符合“開閉原則”。
10.4?適配器模式與橋接模式的聯用
??????? 在軟件開發中，適配器模式通常可以與橋接模式聯合使用。適配器模式可以解決兩個已有接口間不兼容問題，在這種情況下被適配的類往往是一個黑盒子，有時候我們不想也不能改變這個被適配的類，也不能控制其擴展。適配器模式通常用于現有系統與第三方產品功能的集成，采用增加適配器的方式將第三方類集成到系統中。橋接模式則不同，用戶可以通過接口繼承或類繼承的方式來對系統進行擴展。
??????? 橋接模式和適配器模式用于設計的不同階段，橋接模式用于系統的初步設計，對于存在兩個獨立變化維度的類可以將其分為抽象化和實現化兩個角色，使它們可以分別進行變化；而在初步設計完成之后，當發現系統與已有類無法協同工作時，可以采用適配器模式。但有時候在設計初期也需要考慮適配器模式，特別是那些涉及到大量第三方應用接口的情況。
??????? 下面通過一個實例來說明適配器模式和橋接模式的聯合使用：
??????? 在某系統的報表處理模塊中，需要將報表顯示和數據采集分開，系統可以有多種報表顯示方式也可以有多種數據采集方式，如可以從文本文件中讀取數據，也可以從數據庫中讀取數據，還可以從Excel文件中獲取數據。如果需要從Excel文件中獲取數據，則需要調用與Excel相關的API，而這個API是現有系統所不具備的，該API由廠商提供。使用適配器模式和橋接模式設計該模塊。
??????? 在設計過程中，由于存在報表顯示和數據采集兩個獨立變化的維度，因此可以使用橋接模式進行初步設計；為了使用Excel相關的API來進行數據采集則需要使用適配器模式。系統的完整設計中需要將兩個模式聯用，如圖10-6所示：
10.5?橋接模式總結
??????? 橋接模式是設計Java虛擬機和實現JDBC等驅動程序的核心模式之一，應用較為廣泛。在軟件開發中如果一個類或一個系統有多個變化維度時，都可以嘗試使用橋接模式對其進行設計。橋接模式為多維度變化的系統提供了一套完整的解決方案，并且降低了系統的復雜度。
1.主要優點
??????? 橋接模式的主要優點如下：
??????? (1)分離抽象接口及其實現部分。橋接模式使用“對象間的關聯關系”解耦了抽象和實現之間固有的綁定關系，使得抽象和實現可以沿著各自的維度來變化。所謂抽象和實現沿著各自維度的變化，也就是說抽象和實現不再在同一個繼承層次結構中，而是“子類化”它們，使它們各自都具有自己的子類，以便任何組合子類，從而獲得多維度組合對象。
??????? (2)在很多情況下，橋接模式可以取代多層繼承方案，多層繼承方案違背了“單一職責原則”，復用性較差，且類的個數非常多，橋接模式是比多層繼承方案更好的解決方法，它極大減少了子類的個數。
??????? (3)橋接模式提高了系統的可擴展性，在兩個變化維度中任意擴展一個維度，都不需要修改原有系統，符合“開閉原則”。
2.主要缺點
??????? 橋接模式的主要缺點如下：
??????? (1)橋接模式的使用會增加系統的理解與設計難度，由于關聯關系建立在抽象層，要求開發者一開始就針對抽象層進行設計與編程。
??????? (2)橋接模式要求正確識別出系統中兩個獨立變化的維度，因此其使用范圍具有一定的局限性，如何正確識別兩個獨立維度也需要一定的經驗積累。
3.適用場景
??????? 在以下情況下可以考慮使用橋接模式：
??????? (1)如果一個系統需要在抽象化和具體化之間增加更多的靈活性，避免在兩個層次之間建立靜態的繼承關系，通過橋接模式可以使它們在抽象層建立一個關聯關系。
??????? (2)“抽象部分”和“實現部分”可以以繼承的方式獨立擴展而互不影響，在程序運行時可以動態將一個抽象化子類的對象和一個實現化子類的對象進行組合，即系統需要對抽象化角色和實現化角色進行動態耦合。
??????? (3)一個類存在兩個（或多個）獨立變化的維度，且這兩個（或多個）維度都需要獨立進行擴展。
??????? (4)對于那些不希望使用繼承或因為多層繼承導致系統類的個數急劇增加的系統，橋接模式尤為適用。
|
總結
以上是生活随笔為你收集整理的处理多维度变化——桥接模式的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： elasticsearch说了一些了，这
- 下一篇： 不兼容结构的协调——适配器模式