1. 程式人生 > >JAVA設計模式(07):結構型-橋接模式(Bridge)

JAVA設計模式(07):結構型-橋接模式(Bridge)

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

1 跨平臺影象瀏覽系統

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

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

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

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

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

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

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

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

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

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

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

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充當抽象類,其子類JPGImagePNGImageBMPImageGIFImage充當擴充抽象類;ImageImp充當實現類介面,其子類WindowsImpLinuxImpUnixImp充當具體實現類。完整程式碼如下所示:
  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