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

1 跨平臺影象瀏覽系統

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

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

        在圖1的初始設計方案中，使用了一種多層繼承結構，Image

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

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

       (1)由於採用了多層繼承結構，導致系統中類的個數急劇增加，圖1

中，在各種影象的作業系統實現層提供了12個具體類，加上各級抽象層的類，系統中類的總個數達到了17個，在該設計方案中，具體層的類的個數 = 所支援的影象檔案格式數×所支援的作業系統數。

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

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

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

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

2 橋接模式概述

        橋接模式是一種很實用的結構型設計模式，如果軟體系統中某個類存在兩個獨立變化的維度，通過該模式可以將這兩個維度分離出來，使兩者可以獨立擴充套件，讓系統更加符合“單一職責原則”。與多層繼承方案不同，它將兩個獨立變化的維度設計為兩個獨立的繼承等級結構，並且在抽象層建立一個抽象關聯，該關聯關係類似一條連線兩個獨立繼承結構的橋，故名橋接模式。

        橋接模式用一種巧妙的方式處理多層繼承存在的問題，用抽象關聯取代了傳統的多層繼承，將類之間的靜態繼承關係轉換為動態的物件組合關係，使得系統更加靈活，並易於擴充套件，同時有效控制了系統中類的個數。橋接定義如下：

橋接模式(Bridge Pattern)：將抽象部分與它的實現部分分離，使它們都可以獨立地變化。它是一種物件結構型模式，又稱為柄體(Handle and Body)模式或介面(Interface)模式。

        橋接模式的結構與其名稱一樣，存在一條連線兩個繼承等級結構的橋，橋接模式結構如圖3所示：

        在橋接模式結構圖中包含如下幾個角色：

●Abstraction（抽象類）：用於定義抽象類的介面，它一般是抽象類而不是介面，其中定義了一個Implementor（實現類介面）型別的物件並可以維護該物件，它與Implementor之間具有關聯關係，它既可以包含抽象業務方法，也可以包含具體業務方法。

●RefinedAbstraction（擴充抽象類）：擴充由Abstraction定義的介面，通常情況下它不再是抽象類而是具體類，它實現了在Abstraction中宣告的抽象業務方法，在RefinedAbstraction中可以呼叫在Implementor中定義的業務方法。

●Implementor（實現類介面）：定義實現類的介面，這個介面不一定要與Abstraction的介面完全一致，事實上這兩個介面可以完全不同，一般而言，Implementor介面僅提供基本操作，而Abstraction定義的介面可能會做更多更復雜的操作。Implementor介面對這些基本操作進行了宣告，而具體實現交給其子類。通過關聯關係，在Abstraction中不僅擁有自己的方法，還可以呼叫到Implementor中定義的方法，使用關聯關係來替代繼承關係。

●ConcreteImplementor（具體實現類）：具體實現Implementor介面，在不同的ConcreteImplementor中提供基本操作的不同實現，在程式執行時，ConcreteImplementor物件將替換其父類物件，提供給抽象類具體的業務操作方法。

        橋接模式是一個非常有用的模式，在橋接模式中體現了很多面向物件設計原則的思想，包括“單一職責原則”、“開閉原則”、“合成複用原則”、“里氏代換原則”、“依賴倒轉原則”等。熟悉橋接模式有助於我們深入理解這些設計原則，也有助於我們形成正確的設計思想和培養良好的設計風格。

        在使用橋接模式時，我們首先應該識別出一個類所具有的兩個獨立變化的維度，將它們設計為兩個獨立的繼承等級結構，為兩個維度都提供抽象層，並建立抽象耦合。通常情況下，我們將具有兩個獨立變化維度的類的一些普通業務方法和與之關係最密切的維度設計為“抽象類”層次結構（抽象部分），而將另一個維度設計為“實現類”層次結構（實現部分）。例如：對於毛筆而言，由於型號是其固有的維度，因此可以設計一個抽象的毛筆類，在該類中宣告並部分實現毛筆的業務方法，而將各種型號的毛筆作為其子類；顏色是毛筆的另一個維度，由於它與毛筆之間存在一種“設定”的關係，因此我們可以提供一個抽象的顏色介面，而將具體的顏色作為實現該介面的子類。在此，型號可認為是毛筆的抽象部分，而顏色是毛筆的實現部分，結構示意圖如圖4所示：

       在圖4中，如果需要增加一種新型號的毛筆，只需擴充套件左側的“抽象部分”，增加一個新的擴充抽象類；如果需要增加一種新的顏色，只需擴充套件右側的“實現部分”，增加一個新的具體實現類。擴充套件非常方便，無須修改已有程式碼，且不會導致類的數目增長過快。

    在具體編碼實現時，由於在橋接模式中存在兩個獨立變化的維度，為了使兩者之間耦合度降低，首先需要針對兩個不同的維度提取抽象類和實現類介面，並建立一個抽象關聯關係。對於“實現部分”維度，典型的實現類介面程式碼如下所示：

1. interfaceImplementor{
2. publicvoid operationImpl();
3. }

        在實現Implementor介面的子類中實現了在該介面中宣告的方法，用於定義與該維度相對應的一些具體方法。

        對於另一“抽象部分”維度而言，其典型的抽象類程式碼如下所示：

1. abstractclassAbstraction{
2. protectedImplementor impl;//定義實現類介面物件
3. publicvoid setImpl(Implementor impl){
4. this.impl=impl;
5. }
6. publicabstractvoid operation();//宣告抽象業務方法
7. }

        在抽象類Abstraction中定義了一個實現類介面型別的成員物件impl，再通過注入的方式給該物件賦值，一般將該物件的可見性定義為protected，以便在其子類中訪問Implementor的方法，其子類一般稱為擴充抽象類或細化抽象類(RefinedAbstraction)，典型的RefinedAbstraction類程式碼如下所示：

1. classRefinedAbstractionextendsAbstraction{
2. publicvoid operation(){
3. //業務程式碼
4. impl.operationImpl();//呼叫實現類的方法
5. //業務程式碼
6. }
7. }

      對於客戶端而言，可以針對兩個維度的抽象層程式設計，在程式執行時再動態確定兩個維度的子類，動態組合物件，將兩個獨立變化的維度完全解耦，以便能夠靈活地擴充任一維度而對另一維度不造成任何影響。

思考 如果系統中存在兩個以上的變化維度，是否可以使用橋接模式進行處理？如果可以，系統該如何設計？

3  完整解決方案

        為了減少所需生成的子類數目，實現將作業系統和影象檔案格式兩個維度分離，使它們可以獨立改變，Sunny公司開發人員使用橋接模式來重構跨平臺影象瀏覽系統的設計，其基本結構如圖7-5所示：

         在圖7-5中，Image充當抽象類，其子類JPGImage、PNGImage、BMPImage和GIFImage充當擴充抽象類；ImageImp充當實現類介面，其子類WindowsImp、LinuxImp和UnixImp充當具體實現類。完整程式碼如下所示：

1. //畫素矩陣類：輔助類，各種格式的檔案最終都被轉化為畫素矩陣，不同的作業系統提供不同的方式顯示畫素矩陣
2. classMatrix{
3. //此處程式碼省略
4. }
5. //抽象影象類：抽象類
6. abstractclassImage{
7. protectedImageImp imp;
8. publicvoid setImageImp(ImageImp imp){
9. this.imp = imp;
10. }
11. publicabstractvoid parseFile(String fileName);
12. }
13. //抽象作業系統實現類：實現類介面
14. interfaceImageImp{
15. publicvoid doPaint(Matrix m);//顯示畫素矩陣m
16. }
17. //Windows作業系統實現類：具體實現類
18. classWindowsImpimplementsImageImp{
19. publicvoid doPaint(Matrix m){
20. //呼叫Windows系統的繪製函式繪製畫素矩陣
21. System.out.print("在Windows作業系統中顯示影象：");
22. }
23. }
24. //Linux作業系統實現類：具體實現類
25. classLinuxImpimplementsImageImp{
26. publicvoid doPaint(Matrix m){
27. //呼叫Linux系統的繪製函式繪製畫素矩陣
28. System.out.print("在Linux作業系統中顯示影象：");
29. }
30. }
31. //Unix作業系統實現類：具體實現類
32. classUnixImpimplementsImageImp{
33. publicvoid doPaint(Matrix m){
34. //呼叫Unix系統的繪製函式繪製畫素矩陣
35. System.out.print("在Unix作業系統中顯示影象：");
36. }
37. }
38. //JPG格式影象：擴充抽象類
39. classJPGImageextendsImage{
40. publicvoid parseFile(String fileName){
41. //模擬解析JPG檔案並獲得一個畫素矩陣物件m;
42. Matrix m =newMatrix();
43. imp.doPaint(m);
44. System.out.println(fileName +"，格式為JPG。");
45. }
46. }
47. //PNG格式影象：擴充抽象類
48. classPNGImageextendsImage{
49. publicvoid parseFile(String fileName){
50. //模擬解析PNG檔案並獲得一個畫素矩陣物件m;
51. Matrix m =newMatrix();
52. imp.doPaint(m);
53. System.out.println(fileName +"，格式為PNG。");
54. }
55. }
56. //BMP格式影象：擴充抽象類
57. classBMPImageextendsImage{
58. publicvoid parseFile(String fileName){
59. //模擬解析BMP檔案並獲得一個畫素矩陣物件m;
60. Matrix m =newMatrix();
61. imp.doPaint(m);
62. System.out.println(fileName +"，格式為BMP。");
63. }
64. }
65. //GIF格式影象：擴充抽象類
66. classGIFImageextendsImage{
67. publicvoid parseFile(String fileName){
68. //模擬解析GIF檔案並獲得一個畫素矩陣物件m;
69. Matrix m =newMatrix();
70. imp.doPaint(m);
71. System.out.println(fileName +"，格式為GIF。");
72. }
73. }

        為了讓系統具有更好的靈活性和可擴充套件性，我們引入了配置檔案，將具體擴充抽象類和具體實現類類名都儲存在配置檔案中，再通過反射生成物件，將生成的具體實現類物件注入到擴充抽象類物件中，其中，配置檔案config.xml的程式碼如下所示：

1. <?xml version="1.0" encoding="UTF-8"?>
2. <config>
3. <image>com.somnus.designPatterns.bridge.JPGImage</image>
4. <os>com.somnus.designPatterns.bridge.WindowsImp</os>
5. </config>

        用於讀取配置檔案config.xml並反射生成物件的XMLUtil類的程式碼如下所示：

1. publicclassXMLUtil{
2. //該方法用於從XML配置檔案中提取具體類類名，並返回一個例項物件
3. publicstaticObject getBean(String args)throwsException{
4. SAXReader reader =newSAXReader();
5. String path =XMLUtil.class.getClassLoader().
6. getResource("com/somnus/designPatterns/bridge/config.xml").getPath();
7. Document document = reader.read(newFile(path));
8. String cName =null;
9. if(args.equals("image")){
10. cName = document.selectSingleNode("/config/image").getText();
11. }elseif(args.equals("os")){
12. //獲取第二個包含類名的節點，即具體實現類
13. cName = document.selectSingleNode("/config/os").getText();
14. }
15. //通過類名生成例項物件並將其返回
16. Class<?> c =Class.forName(cName);
17. Object obj = c.newInstance();
18. return obj
    相關推薦

    JAVA設計模式（07）：結構型-橋接模式（Bridge）

         在正式介紹橋接模式之前，我先跟大家談談兩種常見文具的區別，它們是毛筆和蠟筆。假如我們需要大中小3種型號的畫筆，能夠繪製12種不同的顏色，如果使用蠟筆，需要準備3×12 = 36支，但如果使用毛筆的話，只需要提供3種型號的毛筆，外加12個顏料盒即可，涉及到的物

    設計模式-結構型- 橋接模式（Bridge）

    定義 將抽象部分與它的實現部分分享，使它們都可以獨立地變化 角色 抽象角色（Abstraction）：定義了抽象類的介面而且維護著一個指向實現角色的引用 具體抽象角色（RefinedAbstr

    【設計模式筆記】結構型--橋接模式

    橋接（Bridge）模式 　　將抽象與實現部分分離，使得他們都可以獨立的變化。又稱為介面（Interface）模式        體現了單一職責、開閉、合成複用、里氏代換、依賴倒轉原則。 如何使用： 　　1、識別出一個類所具有的兩個獨立變化的維度，將他們設計成兩

    設計模式-結構型-橋接模式

    橋接模式（Bridge）： 　　橋接是用於把抽象化與實現化解耦，使得兩者可以獨立變化。 橋接模式的角色： 　　  　　1）抽象化角色（Abstraction）：它是用於定義抽象介面，通常是抽象類而不是介面，其中定義了一個Implementor(實現介面)型別的物件並可以維護該物件，它與Imp

    Java設計模式簡介（二）：結構型模式

    我們接著討論設計模式，上篇文章我講完了5種建立型模式，這章開始，我將講下7種結構型模式：介面卡模式、裝飾模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。其中物件的介面卡模式是各種模式的起源，我們看下面的圖：   6、介面卡模式（Adapter）： 介面卡模式將某個

    JAVA設計模式（13）：行為型-責任鏈模式（Responsibility）

    “一對二”，“過”，“過”……這聲音熟悉嗎？你會想到什麼？對！紙牌。在類似“鬥地主”這樣的紙牌遊戲中，某人出牌給他的下家，下家看看手中的牌，如果要不起上家的牌則將出牌請求再轉發給他的下家，其下家再進行判斷。一個迴圈下來，如果其他人都要不起該牌，則最初的出牌者可以打出新的牌。在這個過程中，牌作為一個

    面向物件設計的設計模式（二）：結構型模式（附 Demo & UML類圖）

    本篇是面向物件設計系列文章的第三篇，講解的是設計模式中的結構型模式： 外觀模式 介面卡模式 橋接模式 代理模式 裝飾者模式 享元模式 該系列前面的兩篇文章： 面向物件設計的六大設計原則（附 Demo 及 UML 類圖） 面向物件設計的設計模式（一）：建

    人人都能讀懂的設計模式（2）：結構型模式

    用最簡單的語言，解釋設計模式。 雖然示例程式碼是用 PHP7 實現的，但因為概念是一樣的，所以語言並不會阻礙大家理解設計模式。 結構型設計模式 概述 結構型設計模式主要關注物件組合，換句話說，關注實體之間如何互相使用。 或者還有另外一個解釋，結構型設計模式有助於回

    設計模式（11）—— 結構型 ——橋接（bridge）

    介紹 定義：將抽象部分與它的具體實現部分分離，使它們都可以獨立地變化 說明：通過組合的方式建立兩個類之間的聯絡，而不是繼承 型別：結構型 適用場景： 抽象和具體實現之間增加更多的靈活性 一個類存在兩個（或多

    Java設計模式（九）之結構型模式：外觀模式

    一、定義： 所謂外觀模式，就是提供一個統一的介面，用來訪問子系統中的一群介面。 外觀模式定義了一個高層介面，讓子系統更容易使用。如下圖，是使用外觀模式後將子系統的使用變得更加簡單。 在引入外觀模式後，客戶只需要與外觀角色打交道，客戶與子系統的複雜關係由外觀角色來實現

    Java設計模式（十二）之結構型模式：享元模式

    一、定義： 享元模式，也就是說在一個系統中如果有多個相同的物件，那麼只共享一份就可以了，不必每個都去例項化一個物件。比如說一個文本系統，每個字母定一個物件，那麼大小寫字母一共就是52個，那麼就要定義52個物件。如果有一個1M的文字，那麼字母是何其的多，如果每個字母都定義一個

    Java設計模式簡介（四）：行為型模式（下）

    其實每個設計模式都是很重要的一種思想，看上去很熟，其實是因為我們在學到的東西中都有涉及，儘管有時我們並不知道，其實在Java本身的設計之中處處都有體現，像AWT、JDBC、集合類、IO管道或者是Web框架，裡面設計模式無處不在。因為我們篇幅有限，很難講每一個設計模式都講的很詳細。 本章講講

    Java設計模式簡介（三）：行為型模式（上）

    本章講到第三種設計模式——行為型模式，共11種：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、直譯器模式。 先來張圖，看看這11中模式的關係： 第一類：通過父類與子類的關係進行實現。第二類：兩個類之間。第三類：類的狀態。第

    Java設計模式簡介（一）：建立型模式

    設計模式（Design pattern）是一套被反覆使用、多數人知曉的、經過分類編目的、程式碼設計經驗的總結。使用設計模式是為了可重用程式碼、讓程式碼更容易被他人理解、保證程式碼可靠性。 毫無疑問，設計模式於己於他人於系統都是多贏的，設計模式使程式碼編制真正工程化，設計模式是軟體工程的基石，如同大廈

    JAVA設計模式（16）：行為型-策略模式（Strategy）

    俗話說：條條大路通羅馬。在很多情況下，實現某個目標的途徑不止一條，例如我們在外出旅遊時可以選擇多種不同的出行方式，如騎自行車、坐汽車、坐火車或者坐飛機，可根據實際情況（目的地、旅遊預算、旅遊時間等）來選擇一種最適合的出行方式。在制訂旅行計劃時，如果目的地較遠、時間不多，但

    JAVA設計模式（01）：建立型-工廠模式【簡單工廠模式】（Simple Factory）

         工廠模式是最常用的一類建立型設計模式，通常我們所說的工廠模式是指工廠方法模式，它也是使用頻率最高的工廠模式。本章將要學習的簡單工廠模式是工廠方法模式的“小弟”，它不屬於GoF 23種設計模式，但在軟體開發中應用也較為頻繁，通常將它作為學習其他工廠模式的入門。此

    JAVA設計模式（24）：建立型-工廠模式【工廠方法模式】(Factory Method)

    簡單工廠模式雖然簡單，但存在一個很嚴重的問題。當系統中需要引入新產品時，由於靜態工廠方法通過所傳入引數的不同來建立不同的產品，這必定要修改工廠類的原始碼，將違背“開閉原則”，如何實現增加新產品而不影響已有程式碼？工廠方法模式應運而生，本文將介紹第二種工廠模式——工廠方法模

    JAVA設計模式（22）：行為型-直譯器模式（Interpreter）

           Sunny軟體公司欲為某玩具公司開發一套機器人控制程式，在該機器人控制程式中包含一些簡單的英文控制指令，每一個指令對應一個表示式(expression)，該表示式可以是簡單表示式也可以是複合表示式，每一個簡單表示式由移動方向(direction)，移動方式(action)和移動距離(distan

    設計模式彙總：結構型模型（下）

    總體來說設計模式分為三大類： 建立型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。 結構型模式，共七種：介面卡模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享

    設計模式之十八：橋接模式（Bridge）

    ora 它的 pla sin string src ams down ng- 橋接模式： 將抽象部分和它的實現部分相分離開來，以使它們能夠單獨地變化。 UML圖： 主要包含： Abstraction:定義了抽象部分的接口。操作一個實現部分對