設計模式-橋接模式(Bridge)-Java

設計模式-橋接模式-Java

---

目錄

---

---

內容

---

  在正式介紹橋接模式之前，我先跟大家談談兩種常見文具的區別，它們是毛筆和蠟筆。假如我們需要大中小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軟件公司的開發人員針對上述要求，提出了一個初始設計方案，其基本結構如圖1-1所示：

圖1-1 跨平臺圖像瀏覽器系統初始結構圖

1.1、分析

  在圖10-1的初始設計方案中，使用了一種多層繼承結構，Image是抽象父類，而每一種類型的圖像類，如BMPImage、JPGImage等作爲其直接子類，不同的圖像文件格式具有不同的解析方法，可以得到不同的像素矩陣；由於每一種圖像又需要在不同的操作系統中顯示，不同的操作系統在屏幕上顯示像素矩陣有所差異，因此需要爲不同的圖像類再提供一組在不同操作系統顯示的子類，如爲BMPImage提供三個子類BMPWindowsImp、BMPLinuxImp和BMPUnixImp，分別用於在Windows、Linux和Unix三個不同的操作系統下顯示圖像。我們現在對該設計方案進行分析，發現存在如下兩個主要問題：

• (1)：由於採用了多層繼承結構，導致系統中類的個數急劇增加，圖1-1中，在各種圖像的操作系統實現層提供了12個具體類，加上各級抽象層的類，系統中類的總個數達到了17個，在該設計方案中，具體層的類的個數 = 所支持的圖像文件格式數×所支持的操作系統數。
• (2)：系統擴展麻煩，由於每一個具體類既包含圖像文件格式信息，又包含操作系統信息，因此無論是增加新的圖像文件格式還是增加新的操作系統，都需要增加大量的具體類，例如在圖10-1中增加一種新的圖像文件格式TIF，則需要增加3個具體類來實現該格式圖像在3種不同操作系統的顯示；如果增加一個新的操作系統Mac OS，爲了在該操作系統下能夠顯示各種類型的圖像，需要增加4個具體類。這將導致系統變得非常龐大，增加運行和維護開銷。

1.2、解決

  如何解決這兩個問題？我們通過分析可得知，該系統存在兩個獨立變化的維度：圖像文件格式和操作系統，如圖1.2-1所示：

圖1.2-1 跨平臺圖像瀏覽器中存在的兩個獨立變化維度示意圖

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

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

2、橋接模式概述

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

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

2.1、橋接模式定義

• 橋接模式（Bridge Pattern）：將抽象部分與它的實現部分分離，使他們都可以獨立地變化。它是一種對象結構型模式，又稱爲柄體（Handle and Body）模式或接口（Interface）模式。

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

圖2.1-1 橋接模式結構圖

2.2、橋接模式結構圖中角色

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

• Abstraction（抽象類）：用於定義抽象類的接口，它一般是抽象類而不是接口，其中定義了一個Implementor（實現類接口）類型的對象並可以維護該對象，它與Implementor之間具有關聯關係，它既可以包含抽象業務方法，也可以包含具體業務方法。
• RefinedAbstraction（擴充抽象類）：擴充由Abstraction定義的接口，通常情況下它不再是抽象類而是具體類，它實現了在Abstraction中聲明的抽象業務方法，在RefinedAbstraction中可以調用在Implementor中定義的業務方法。
• Implementor（實現接口類）：定義實現類的接口，這個接口不一定要與Abstraction的接口完全一致，事實上這兩個接口可以完全不同，一般而言，Implementor接口僅提供基本操作，而Abstraction定義的接口可能會做更多更復雜的操作。Implementor接口對這些基本操作進行了聲明，而具體實現交給其子類。通過關聯關係，在Abstraction中不僅擁有自己的方法，還可以調用到Implementor中定義的方法，使用關聯關係來替代繼承關係。
• ConcreteImplementor（具體實現類）：具體實現Implementor接口，在不同的ConcreteImplementor中提供基本操作的不同實現，在程序運行時，ConcreteImplementor對象將替換其父類對象，提供給抽象類具體的業務操作方法。

2.3、橋接模式使用

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

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

圖2.3-1 毛筆結構示意圖

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

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

interface Implementor {
	public void operationImpl();
}

  在實現Implementor接口的子類中實現了在該接口中聲明的方法，用於定義與該維度相對應的一些具體方法。
  對於另一“抽象部分”維度而言，其典型的抽象類代碼如下所示：

abstract class Abstraction {
	protected Implementor impl; //定義實現類接口對象
	public void setImpl(Implementor impl) {
		this.impl=impl;
	}
	public abstract void operation(); //聲明抽象業務方法
}

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

class RefinedAbstraction extends Abstraction {
	public void operation() {
	//業務代碼
	impl.operationImpl(); //調用實現類的方法
	//業務代碼
	}
}

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

3、跨平臺圖像瀏覽器系統（橋接模式）完整解決方案

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

圖3-1 跨平臺圖像瀏覽器系統結構圖

  在圖3-1中，Image充當抽象類，其子類JPGImage、PNGImage、BMPImage和GIFImage充當擴充抽象類；ImageImp充當實現類接口，其子類WindowsImp、LinuxImp和UnixImp充當具體實現類。完整代碼如下所示：

• Matrix代碼3-1：像素矩陣類（輔助類）

    //像素矩陣類：輔助類，各種格式的文件最終都被轉化爲像素矩陣，不同的操作系統提供不同的實現
    package bridge;
  
    public class Matrix {}
  

• ImageImp代碼3-2：抽象操作系統實現類（實現類接口）

    package bridge;
  
    //抽象操作系統實現類：實現類接口
    public interface ImageImp {
    	public void doPaint(Matrix m); // 顯示像素矩陣
    }
  

• WindowImageImp代碼3-3：Window操作系統實現類（具體實現類）

    package bridge;
  
    //Windows操作系統實現類：具體實現類
    public class WindowImageImp implements ImageImp{
  
    	@Override
    	public void doPaint(Matrix m) {
    		//調用Windows系統的繪製函數繪製像素矩陣
    		System.out.print("在Windows操作系統中顯示圖像：");
    	}
    }
  

• LinuxImageImp代碼3-4：Linux操作系統實現類（具體實現類）

    package bridge;
  
    //Linux操作系統實現類：具體實現類
    public class LinuxImageImp implements ImageImp{
  
    	@Override
    	public void doPaint(Matrix m) {
    		//調用Linux系統的繪製函數繪製像素矩陣
    		System.out.print("在Linux操作系統中顯示圖像：");
    	}
    }
  

• UnixImageImp代碼3-5：Unix操作系統實現類（具體實現類）

    package bridge;
  
    //Unix操作系統實現類：具體實現類
    public class UnixImageImp implements ImageImp{
  
    	@Override
    	public void doPaint(Matrix m) {
    		//調用Unix系統的繪製函數繪製像素矩陣
    		System.out.print("在Unix操作系統中顯示圖像：");
    	}
    }
  

• Image代碼3-6：抽象圖像類（抽象類）

    package bridge;
  
    //抽象圖像類：抽象類
    public abstract class Image {
    	protected ImageImp imp;
    	public void setImageImp(ImageImp imp) {
    		this.imp = imp;
    	}
    	public abstract void parseFile(String fileName);
    }
  

• JPGImage代碼3-7：JPG格式圖像（擴充抽象類）

package bridge;

	//JPG格式圖像：擴充抽象類
	public class JPGImage extends Image{

		@Override
		public void parseFile(String fileName) {
			//模擬解析JPG文件並獲得一個像素矩陣對象m;
			Matrix m = new Matrix();
			imp.doPaint(m);
			System.out.println(fileName + "，格式爲JPG。");
		}
	}

• PNGImage代碼3-8：PNG格式圖像（擴充抽象類）

    package bridge;
  
    //PNG格式圖像：擴充抽象類
    public class PNGImage extends Image{
  
    	@Override
    	public void parseFile(String fileName) {
    		//模擬解析PNG文件並獲得一個像素矩陣對象m;
    		Matrix m = new Matrix();
    		imp.doPaint(m);
    		System.out.println(fileName + "，格式爲PNG。");
    	}
    }
  

• BMPImage代碼3-9：BMP格式圖像（擴充抽象類）

    package bridge;
  
    //BMP格式圖像：擴充抽象類
    public class BMPImage extends Image{
  
    	@Override
    	public void parseFile(String fileName) {
    		//模擬解析BMP文件並獲得一個像素矩陣對象m;
    		Matrix m = new Matrix();
    		imp.doPaint(m);
    		System.out.println(fileName + "，格式爲BMP。");
    	}
    }
  

• GIFImage代碼3-10：GIF格式圖像（擴充抽象類）

    package bridge;
  
    //GIF格式圖像：擴充抽象類
    public class GIFImage extends Image{
  
    	@Override
    	public void parseFile(String fileName) {
    		//模擬解析GIF文件並獲得一個像素矩陣對象m;
    		Matrix m = new Matrix();
    		imp.doPaint(m);
    		System.out.println(fileName + "，格式爲GIF。");
    	}
    }
  

• Utils代碼3-11：工具類

    package bridge;
  
    import java.util.Properties;
  
    public class Utils {
    	public static Object getObject(String args) {
    		try {
    			Properties prop = new Properties();
    			prop.load(Utils.class.getClassLoader().getResourceAsStream("image.properties"));
    			String className = prop.getProperty(args);
    			return (Class.forName(className).newInstance());
    		}catch (Exception e) {
    			e.printStackTrace();
    			return null;
    		}
    	}
    }
  

• Client代碼3-12：客戶端測試類

    package bridge;
  
    public class Client {
    	public static void main(String args[]) {
    		Image image;
    		ImageImp imp;
    		image = (Image)Utils.getObject("image");
    		imp = (ImageImp)Utils.getObject("os");
    		image.setImageImp(imp);
    		image.parseFile("小龍女");
    	}
    }
  

• 測試結果：

    在Windows操作系統中顯示圖像：小龍女，格式爲PNG。
  

  如果需要更換圖像文件格式或者更換操作系統，只需修改配置文件即可，在實際使用時，可以通過分析圖像文件格式後綴名來確定具體的文件格式，在程序運行時獲取操作系統信息來確定操作系統類型，無須使用配置文件。當增加新的圖像文件格式或者操作系統時，原有系統無須做任何修改，只需增加一個對應的擴充抽象類或具體實現類即可，系統具有較好的可擴展性，完全符合“開閉原則”。

4、適配器模式與橋接模式的聯用

  在軟件開發中，適配器模式通常可以與橋接模式聯合使用。適配器模式可以解決兩個已有接口間不兼容問題，在這種情況下被適配的類往往是一個黑盒子，有時候我們不想也不能改變這個被適配的類，也不能控制其擴展。適配器模式通常用於現有系統與第三方產品功能的集成，採用增加適配器的方式將第三方類集成到系統中。橋接模式則不同，用戶可以通過接口繼承或類繼承的方式來對系統進行擴展。

  橋接模式和適配器模式用於設計的不同階段，橋接模式用於系統的初步設計，對於存在兩個獨立變化維度的類可以將其分爲抽象化和實現化兩個角色，使它們可以分別進行變化；而在初步設計完成之後，當發現系統與已有類無法協同工作時，可以採用適配器模式。但有時候在設計初期也需要考慮適配器模式，特別是那些涉及到大量第三方應用接口的情況。

  下面通過一個實例來說明適配器模式和橋接模式的聯合使用：

  在某系統的報表處理模塊中，需要將報表顯示和數據採集分開，系統可以有多種報表顯示方式也可以有多種數據採集方式，如可以從文本文件中讀取數據，也可以從數據庫中讀取數據，還可以從Excel文件中獲取數據。如果需要從Excel文件中獲取數據，則需要調用與Excel相關的API，而這個API是現有系統所不具備的，該API由廠商提供。使用適配器模式和橋接模式
設計該模塊。

  在設計過程中，由於存在報表顯示和數據採集兩個獨立變化的維度，因此可以使用橋接模式進行初步設計；爲了使用Excel相關的API來進行數據採集則需要使用適配器模式。系統的完整設計中需要將兩個模式聯用，如圖4-1所示：

圖4-1 橋接模式與適配器模式聯用示意圖

5、總結

  橋接模式是設計Java虛擬機和實現JDBC等驅動程序的核心模式之一，應用較爲廣泛。在軟件開發中如果一個類或一個系統有多個變化維度時，都可以嘗試使用橋接模式對其進行設計。橋接模式爲多維度變化的系統提供了一套完整的解決方案，並且降低了系統的複雜度。

5.1、優缺點

• 主要優點

  • (1）)分離抽象接口及其實現部分。橋接模式使用“對象間的關聯關係”解耦了抽象和實現之間固有的綁定關係，使得抽象和實現可以沿着各自的維度來變化。所謂抽象和實現沿着各自維度的變化，也就是說抽象和實現不再在同一個繼承層次結構中，而是“子類化”它們，使它們各自都具有自己的子類，以便任何組合子類，從而獲得多維度組合對象。
  • (2))在很多情況下，橋接模式可以取代多層繼承方案，多層繼承方案違背了“單一職責原則”，複用性較差，且類的個數非常多，橋接模式是比多層繼承方案更好的解決方法，它極大減少了子類的個數。
  • (3)橋接模式提高了系統的可擴展性，在兩個變化維度中任意擴展一個維度，都不需要修改原有系統，符合“開閉原則”。

• 主要缺點

  • (1)橋接模式的使用會增加系統的理解與設計難度，由於關聯關係建立在抽象層，要求開發者一開始就針對抽象層進行設計與編程。
  • (2))橋接模式要求正確識別出系統中兩個獨立變化的維度，因此其使用範圍具有一定的侷限性，如何正確識別兩個獨立維度也需要一定的經驗積累。

5.2、適用場景

  在以下情況下可以考慮使用橋接模式：

• (1)如果一個系統要在抽象化和具體化之間增加更多的靈活性，避免在兩個層次之間建立靜態的繼承關係，通過橋接模式可以使它們在抽象層建立一個關聯關係。
• (2)“抽象部分”和“實現部分”可以以繼承的方式獨立擴展而互不影響，在程序運行時可以動態將一個抽象化子類的對象和一個實現化子類的對象進行組合，即系統需要對抽象化角色和實現化角色進行動態耦合。
• (3)一個類存在兩個（或多個）獨立變化的維度，且這兩個（或多個）維度都需要獨立進行擴展。
• (4)對於那些不希望使用繼承或因爲多層繼承導致系統類的個數急劇增加的系統，橋接模式尤爲適用。

後記 ：

  參考文獻：Java設計模式（劉偉）.pdf。持續更新，歡迎交流，本人QQ:806797785

前端項目源代碼地址：https://gitee.com/gaogzhen/vue-leyou
後端JAVA源代碼地址:https://gitee.com/gaogzhen/JAVA