結構模式--之--橋樑模式

橋樑模式的用意是「將抽象化與實現化脫耦，使得兩者能夠獨立地變化」

 

所謂脫耦，就是兩個實體的行爲的某種強關聯。而將它們的強關聯去掉，就是耦合的解脫或稱爲脫耦。或者說，將它們之間的強關聯改換成弱關聯。

所強關聯，就是在編譯時期已經肯定的，沒法在運行期間動態改變的關聯。所謂弱關聯，就是能夠動態地肯定而且能夠在運行時期動態地改變的關聯。在java語言中，類繼承關係是強關聯，而聚合有關係是弱關聯。

橋樑模式中的所謂脫耦，就是指在一個軟件系統的抽象化和實現化之間使用組合/聚合關係而不是繼承關係，從而使二者能夠相對獨立地變化。這就是橋樑模式的用意。

 

橋樑模式的系統含有兩個等級結構：

1.由抽象化角色和修正抽象化角色組成的抽象化等級結構

2.由實現化角色和兩個具體實現化角色所組成的實現化等級結構。

橋樑模式所涉及的角色：

1.抽象化（Abstraction）角色：抽象化給出的定義，並保存一個對實現化對象的引用

2.修正抽象化(Refined Abstraction)角色：擴展抽象化角色，改變和修正父類對抽象化的定義

3.實現化（Implementor）角色:這個角色給出實現化角色的接口，但不給出具體的實現，這個接口不必定和抽象化角色的接口相同，實際上，這兩個接口能夠很是 不同。實現化角色應當只給出底層操做，而抽象化角色應當只給出基於底層操做的更高一層的操做。

4.具體實現化（Concrete Implementor）角色：這個角色給出實現化角色接口的具體實現。

通常而言，實現化角色中的每個方法都應當有一個抽象化角色中某一個方法與之相對應。可是反過來則不必定。換言之，抽象化角色的接口比實現化角色的接口寬。抽象化角色除了提供與實現化角色相關的方法外，還可能提供其它的商業方法，而實現化角色則每每僅爲實現抽象化角色的相關行爲而存在。

 

救命代碼：

 1 public class BridgeTest {
 2     public static void main(String[] args) {
 3         Abstraction imp = new RefinedAbstraction(new ConcreteImplementorA());
 4         imp.operation();
 5     }
 6 
 7 }
 8 //抽象化角色
 9 abstract class Abstraction{
10     //實現化角色
11     protected Implementor imp;
12     
13     //經過向實現化角色委派完成
14     public void operation(){
15         imp.operationImp();
16     }
17 }
18 //修正抽象化角色
19 class RefinedAbstraction extends Abstraction{
20     public RefinedAbstraction(Implementor imp){
21         this.imp = imp;
22     }
23     
24     //修正化角色能夠置換掉實現化角色的方法
25     public void operation(){
26         System.out.println("Do anotherThing....");
27     }
28 }
29 //實現化角色
30 abstract class Implementor{
31     public abstract void operationImp();
32 }
33 
34 //具體實現化角色
35 class ConcreteImplementorA extends Implementor{
36 
37     @Override
38     public void operationImp() {
39         System.out.println("Do something....");
40     }
41     
42 }

橋樑模式是「對變化的封裝」原則以及組合、聚合複用原則的極好的例子。在飛機制造系統中，飛機的種類和製造商表明兩個不一樣的變化因素，而這兩個變化因素須要獨立地變化。按照對變化的封裝原則，它們應當被封裝到繼承的等級結構中，而這兩個等級結構之間應當選擇使用聚合關係，避免出現靜態的強耦合，這就致使了橋樑模式的設計方案。

 

什麼狀況下使用橋樑模式？

1.若是一個系統須要在構件的抽象化角色和具體化角色之間增長更多的靈活性，避免在兩個層次之間創建靜態的聯繫

2.設計要求實現化角色的任何改變不該當影響客戶端，或者說實現化角色的改變對客戶端是徹底透明的

3.一個構件有多於一個的抽象化角色和實現化角色，系統須要它們之間進行動態耦合

4.雖然在系統中使用繼承是沒有問題，可是因爲抽象化角色和具體化角色須要獨立變化，設計要求須要獨立管理這二者。