1. 橋接模式
1.1 簡(jiǎn)介
??Bridge 模式將抽象和行為劃分開,各自可以獨(dú)立地變化,但又能動(dòng)態(tài)的結(jié)合。它是一種對(duì)象結(jié)構(gòu)型模式,又稱為柄體(Handle and Body)模式或接口(Interface)模式。
??將抽象部分與它的實(shí)現(xiàn)部分分離,使他們都可以獨(dú)立地變化?!皩⒊橄蟛糠峙c它的實(shí)現(xiàn)部分分離”指實(shí)現(xiàn)系統(tǒng)可能有多個(gè)角度分類,每一種分類都可能變化,那么就把這種多角度分離出來讓它們獨(dú)立變化,減少它們之間的耦合。
1.2 誕生背景
??如果有一個(gè)需求,需要?jiǎng)?chuàng)建不同的圖形,并且每個(gè)圖形都有可能會(huì)有不同的顏色。我們可以利用繼承的方式來設(shè)計(jì)類的關(guān)系:

??我們發(fā)現(xiàn)繼承會(huì)衍生出很多的類,假如我們?cè)僭黾右粋€(gè)形狀或再增加一種顏色,就需要?jiǎng)?chuàng)建更多的類。
??試想,在一個(gè)有多種可能會(huì)變化的維度的系統(tǒng)中,用繼承方式會(huì)造成類爆炸,擴(kuò)展起來不靈活。每次在一個(gè)維度上新增一個(gè)具體實(shí)現(xiàn)都要增加多個(gè)子類。為了更加靈活的設(shè)計(jì)系統(tǒng),我們此時(shí)可以考慮使用橋接模式。
1.3 橋接模式結(jié)構(gòu)
橋接模式uml:

橋接模式角色:
Abstraction(抽象類):用于定義抽象類的接口,它一般是抽象類而不是接口,其中定義了一個(gè)Implementor(實(shí)現(xiàn)類接口)類型的對(duì)象并可以維護(hù)該對(duì)象,它與Implementor之間具有關(guān)聯(lián)關(guān)系,它既可以包含抽象業(yè)務(wù)方法,也可以包含具體業(yè)務(wù)方法。
RefinedAbstraction(擴(kuò)充抽象類):擴(kuò)充由Abstraction定義的接口,通常情況下它不再是抽象類而是具體類,它實(shí)現(xiàn)了在Abstraction中聲明的抽象業(yè)務(wù)方法,在RefinedAbstraction中可以調(diào)用在Implementor中定義的業(yè)務(wù)方法。
Implementor(實(shí)現(xiàn)類接口):定義實(shí)現(xiàn)類的接口,這個(gè)接口不一定要與Abstraction的接口完全一致,事實(shí)上這兩個(gè)接口可以完全不同,一般而言,Implementor接口僅提供基本操作,而Abstraction定義的接口可能會(huì)做更多更復(fù)雜的操作。Implementor接口對(duì)這些基本操作進(jìn)行了聲明,而具體實(shí)現(xiàn)交給其子類。通過關(guān)聯(lián)關(guān)系,在Abstraction中不僅擁有自己的方法,還可以調(diào)用到Implementor中定義的方法,使用關(guān)聯(lián)關(guān)系來替代繼承關(guān)系。
ConcreteImplementor(具體實(shí)現(xiàn)類):具體實(shí)現(xiàn)Implementor接口,在不同的ConcreteImplementor中提供基本操作的不同實(shí)現(xiàn),在程序運(yùn)行時(shí),ConcreteImplementor對(duì)象將替換其父類對(duì)象,提供給抽象類具體的業(yè)務(wù)操作方法。
2. 示例
??使用橋接模式時(shí),我們把抽象共同部分和行為共同部分各自獨(dú)立開來,原來是準(zhǔn)備放在一個(gè)接口里,現(xiàn)在需要設(shè)計(jì)兩個(gè)接口:抽象接口和行為接口,分別放置抽象和行為。
??以一杯咖啡為例,子類實(shí)現(xiàn)類為四個(gè):中杯加奶、大杯加奶、 中杯不加奶、大杯不加奶。上面四個(gè)子類中有概念重疊,可從另外一個(gè)角度進(jìn)行考慮,這四個(gè)類實(shí)際是兩個(gè)角色的組合:抽象 和行為,其中抽象為:中杯和大杯;行為為:加奶 不加奶(如加橙汁 加蘋果汁)。
??實(shí)現(xiàn)四個(gè)子類在抽象和行為之間發(fā)生了固定的綁定關(guān)系,如果以后動(dòng)態(tài)增加加葡萄汁的行為,就必須再增加兩個(gè)類:中杯加葡萄汁和大杯加葡萄汁。顯然混亂,擴(kuò)展性極差。那我們從分離抽象和行為的角度,使用Bridge模式來實(shí)現(xiàn)。
行為部分:
是否加奶或其他配料的行為接口,CoffeeImp:
public interface CoffeeImp
{
public void pourCoffeeImp();
}
加奶MilkCoffeeImp:
public class MilkCoffeeImp implements CoffeeImp
{
public void pourCoffeeImp()
{
System.out.println("加了美味的牛奶");
}
}
不加奶FragrantCoffeeImp:
public class FragrantCoffeeImp implements CoffeeImp
{
public void pourCoffeeImp()
{
System.out.println("什么也沒加,清香");
}
}
對(duì)象抽象部分:
咖啡大小杯型號(hào)抽象Coffee:
public abstract class Coffee
{
CoffeeImp coffeeImp;
public void setCoffeeImp(CoffeeImp coffeeImp) {
this.CoffeeImp = coffeeImp;
}
public CoffeeImp getCoffeeImp() {return this.CoffeeImp;}
public abstract void pourCoffee();
}
中杯咖啡MediumCoffee:
public class MediumCoffee extends Coffee
{
public MediumCoffee() {setCoffeeImp();}
public void pourCoffee()
{
CoffeeImp coffeeImp = this.getCoffeeImp();
//我們以重復(fù)次數(shù)來說明是沖中杯還是大杯 ,重復(fù)2次是中杯
for (int i = 0; i < 2; i++)
{
coffeeImp.pourCoffeeImp();
}
}
}
大杯咖啡SuperSizeCoffee:
public class SuperSizeCoffee extends Coffee
{
public SuperSizeCoffee() {setCoffeeImp();}
public void pourCoffee()
{
CoffeeImp coffeeImp = this.getCoffeeImp();
//我們以重復(fù)次數(shù)來說明是沖中杯還是大杯 ,重復(fù)5次是大杯
for (int i = 0; i < 5; i++)
{
coffeeImp.pourCoffeeImp();
}
}
}
調(diào)用示例:
public static void main(String[] args) {
// 大杯加奶咖啡
CoffeeImp milk = new MilkCoffeeImp();
Coffee superSizeCoffee = new SuperSizeCoffee(milk);
superSizeCoffee.pourCoffee;
}
3. 總結(jié)
??橋接模式是設(shè)計(jì)Java虛擬機(jī)和實(shí)現(xiàn)JDBC等驅(qū)動(dòng)程序的核心模式之一,應(yīng)用較為廣泛。在軟件開發(fā)中如果一個(gè)類或一個(gè)系統(tǒng)有多個(gè)變化維度時(shí),都可以嘗試使用橋接模式對(duì)其進(jìn)行設(shè)計(jì)。橋接模式為多維度變化的系統(tǒng)提供了一套完整的解決方案,并且降低了系統(tǒng)的復(fù)雜度。
橋接模式優(yōu)點(diǎn):
分離抽象接口及其實(shí)現(xiàn)部分。橋接模式使用“對(duì)象間的關(guān)聯(lián)關(guān)系”解耦了抽象和實(shí)現(xiàn)之間固有的綁定關(guān)系,使得抽象和實(shí)現(xiàn)可以沿著各自的維度來變化。所謂抽象和實(shí)現(xiàn)沿著各自維度的變化,也就是說抽象和實(shí)現(xiàn)不再在同一個(gè)繼承層次結(jié)構(gòu)中,而是“子類化”它們,使它們各自都具有自己的子類,以便任何組合子類,從而獲得多維度組合對(duì)象。
在很多情況下,橋接模式可以取代多層繼承方案,多層繼承方案違背了“單一職責(zé)原則”,復(fù)用性較差,且類的個(gè)數(shù)非常多,橋接模式是比多層繼承方案更好的解決方法,它極大減少了子類的個(gè)數(shù)。
橋接模式提高了系統(tǒng)的可擴(kuò)展性,在兩個(gè)變化維度中任意擴(kuò)展一個(gè)維度,都不需要修改原有系統(tǒng),符合“開閉原則”。
橋接模式缺點(diǎn):
橋接模式的使用會(huì)增加系統(tǒng)的理解與設(shè)計(jì)難度,由于關(guān)聯(lián)關(guān)系建立在抽象層,要求開發(fā)者一開始就針對(duì)抽象層進(jìn)行設(shè)計(jì)與編程。
橋接模式要求正確識(shí)別出系統(tǒng)中兩個(gè)獨(dú)立變化的維度,因此其使用范圍具有一定的局限性,如何正確識(shí)別兩個(gè)獨(dú)立維度也需要一定的經(jīng)驗(yàn)積累。
橋接模式適用場(chǎng)景:
如果一個(gè)系統(tǒng)需要在抽象化和具體化之間增加更多的靈活性,避免在兩個(gè)層次之間建立靜態(tài)的繼承關(guān)系,通過橋接模式可以使它們?cè)诔橄髮咏⒁粋€(gè)關(guān)聯(lián)關(guān)系。
“抽象部分”和“實(shí)現(xiàn)部分”可以以繼承的方式獨(dú)立擴(kuò)展而互不影響,在程序運(yùn)行時(shí)可以動(dòng)態(tài)將一個(gè)抽象化子類的對(duì)象和一個(gè)實(shí)現(xiàn)化子類的對(duì)象進(jìn)行組合,即系統(tǒng)需要對(duì)抽象化角色和實(shí)現(xiàn)化角色進(jìn)行動(dòng)態(tài)耦合。
一個(gè)類存在兩個(gè)(或多個(gè))獨(dú)立變化的維度,且這兩個(gè)(或多個(gè))維度都需要獨(dú)立進(jìn)行擴(kuò)展。
對(duì)于那些不希望使用繼承或因?yàn)槎鄬永^承導(dǎo)致系統(tǒng)類的個(gè)數(shù)急劇增加的系統(tǒng),橋接模式尤為適用。