橋樑模式（Bridge Patter）也叫做橋接模式，是一個比較簡單的模式。
定義：
將抽象和實現解耦，使得兩者可以獨立地變化。
通用類圖：
● Abstraction——抽象化角色
它主要的職責是定義出該角色的行爲，同時保存一個對實現化角色的引用，該角色一般是抽象類。
● Implementro——實現化角色
它是接口或者抽象類，定義角色必須的行爲和屬性。
● RefinedAbstraction——修正抽象化角色
它引用實現化角色對抽象化角色進行修正。
● ConcreteImplementor——具體實現化角色
它實現接口或抽象類定義的方法和屬性。
其中imp的地方就是一個組合。Abstraction就是飲料這個例子裏的杯子。，它的子類RefinedAbstraction就是杯子的大小等型號。Implementor是加的物品類類，ConcreteImplementorA和ConcreteImplementorB分別是加糖和檸檬。
整個設計模式的關鍵就是組合的使用。
通用代碼：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
/** *
實現化角色 *
*
@author Administrator *
*/public interface Implementor
{ //
基本方法 public void doSomething(); public void doAnything();} |
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
/** *
具體實現化角色 *
*
@author Administrator *
*/public class ConcreteImplementor1
implements Implementor
{ public void doAnything()
{ //
業務處理邏輯 } public void doSomething()
{ //
業務處理邏輯 }} |
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
/** *
具體實現化角色 *
*
@author Administrator *
*/public class ConcreteImplementor2
implements Implementor
{ public void doAnything()
{ //
業務處理邏輯 } public void doSomething()
{ //
業務處理邏輯 }} |
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
/** *
抽象化角色 *
*
@author Administrator *
*/public abstract class Abstraction
{ //
定義對實現化角色的引用 private Implementor
imp; //
約束子類必須實現該構造函數 public Abstraction(Implementor
_imp) { this.imp
= _imp; } //
自身的行爲和屬性 public void request()
{ this.imp.doSomething(); } //
獲得實現化角色 public Implementor
getImp() { return this.imp; }} |
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
/** *
具體抽象化角色 *
*
@author Administrator *
*/public class RefinedAbstraction
extends Abstraction
{ //
覆寫構造函數 public RefinedAbstraction(Implementor
_imp) { super(_imp); } //
修正父類的行爲 @Override public void request()
{ /* *
業務處理 */ super.request(); super.getImp().doAnything(); }} |
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
/** *
場景類 *
*
@author Administrator *
*/public class Client
{ /** *
@param args */ public static void main(String[]
args) { //
定義一個實現化角色 Implementor
imp = new ConcreteImplementor1(); //
定義一個抽象化角色 Abstraction
abs = new RefinedAbstraction(imp); //
執行行文 abs.request(); }} |
橋樑模式是一個非常簡單的模式，它只是使用了類間的聚合關係、繼承、覆寫等常用功能，但是它卻提供了一個非常清晰、穩定的架構。
理解橋接模式，重點需要理解如何將抽象化(Abstraction)與實現化(Implementation)脫耦，使得二者可以獨立地變化。
•抽象化：抽象化就是忽略一些信息，把不同的實體當作同樣的實體對待。在面向對象中，將對象的共同性質抽取出來形成類的過程即爲抽象化的過程。
•實現化：針對抽象化給出的具體實現，就是實現化，抽象化與實現化是一對互逆的概念，實現化產生的對象比抽象化更具體，是對抽象化事物的進一步具體化的產物。
•脫耦：脫耦就是將抽象化和實現化之間的耦合解脫開，或者說是將它們之間的強關聯改換成弱關聯，將兩個角色之間的繼承關係改爲關聯關係。
橋樑模式的優點：
● 抽象和實現分離
這是橋樑模式的主要特點，它完全是爲了解決繼承的缺點而提出的設計模式。在該模式下，實現可以不受抽象的約束，不用再綁定在一個固定的抽象層次上。
● 優秀的擴展能力
● 實現細節對客戶透明
客戶不用關心細節的實現，它已經由抽象層通過聚合關係完成了封裝。
橋樑模式的使用場景：
● 不希望或不適用使用繼承的場景
例如繼承層次過渡、無法更細化設計顆粒等場景，需要考慮使用橋樑模式。
● 接口或抽象類不穩定的場景
明知道接口不穩定還想通過實現或繼承來實現業務需求，那是得不償失的，也是比較失敗的做法。
● 重用性要求較高的場景
設計的顆粒度越細，則被重用的可能性就越大，而採用繼承則受父類的限制，不可能出現太細的顆粒度。
橋樑模式的注意事項：
使用橋樑模式時主要考慮如何拆分抽象和實現，並不是一涉及繼承就要考慮使用該模式，那還要繼承幹什麼。
橋樑模式的意圖還是對變化的封裝，儘量把可能變化的因素封裝到最細、最小的邏輯單元中，避免風險擴散。
系統設計時，發現類的繼承有N層時，可以考慮使用橋樑模式。