Java設計模式—橋梁模式

終于又碰到了一個簡單點的模式了。

橋梁模式也叫做橋接模式，定義如下：

               将抽象和實作解耦，使得兩者可以獨立地變化。

這句話也太難了解了，橋梁模式是為了解決類繼承的缺點而設計的。一個類想擁有另一個類的方法，可以不繼承，隻需要鋪設一個橋梁架過去就OK了。

通用類圖如下：

角色介紹：

● Abstraction——抽象化角色

它的主要職責是定義出該角色的行為，同時儲存一個對實作化角色的引用，該角色一般是抽象類。

● Implementor——實作化角色

它是接口或者抽象類，定義角色必需的行為和屬性。

● Refined Abstraction——修正抽象化角色

它引用實作化角色對抽象化角色進行修正。

● Concrete Implementor——具體實作化角色

它實作接口或抽象類定義的方法和屬性。

通用源代碼：

//實作化角色
public interface Implementor {
     //基本方法
     public void doSomething();
     public void doAnything();
}      

它沒有任何特殊的地方，就是一個一般的接口，定義要實作的方法。

//具體實作化角色
public class ConcreteImplementor1 implements Implementor{
     public void doSomething(){
             //業務邏輯處理
     }
     public void doAnything(){
             //業務邏輯處理
     }
}
public class ConcreteImplementor2 implements Implementor{
     public void do Something(){
             //業務邏輯處理
}
     public void do Anything(){
             //業務邏輯處理
     }
}      

上面定義了兩個具體實作化角色代表兩個不同的業務邏輯。

抽象化角色
public abstract class Abstraction {
     //定義對實作化角色的引用
     private Implementor imp;
     //限制子類必須實作該構造函數
     public Abstraction(Implementor _imp){
             this.imp = _imp;
     }
     //自身的行為和屬性
     public void request(){
             this.imp.do Something();
     }
     //獲得實作化角色
     public Implementor getImp(){
             return imp;
     }
}      

為什麼要增加一個構造函數？答案是為了提醒子類，你必須做這項工作，指定實作者，特别是已經明确了實作者，則盡量清晰明确地定義出來。

具體抽象化角色
public class RefinedAbstraction extends Abstraction {
     //覆寫構造函數
     public RefinedAbstraction(Implementor _imp){
             super(_imp);
     }
     //修正父類的行為
     @Override
     public void request(){
             /*
              * 業務處理...
              */
             super.request();
             super.get Imp().do Anything();
     }
}      

測試類

public class Client {
     public static void main(String[] args) {
             //定義一個實作化角色
             Implementor imp = new ConcreteImplementor1();
             //定義一個抽象化角色
             Abstraction abs = new RefinedAbstraction(imp);
             //執行行文
             abs.request();
     }
}      

橋梁模式是一個非常簡單的模式，它隻是使用了類間的聚合關系、繼承、覆寫等常用功能，但是它卻提供了一個非常清晰、穩定的架構。

       各位請仔細瞅瞅橋梁模式，就是ConcreteImplementor1類有兩個方法：dosomething( )和doanything( )。然後有一個類RefinedAbstraction就也想擁有這兩方法，但是又不想實作繼承關系，是以利用了一個橋梁就OK了。

橋梁模式的優點：

● 抽象和實作分離

這也是橋梁模式的主要特點，它完全是為了解決繼承的缺點而提出的設計模式。在該模式下，實作可以不受抽象的限制，不用再綁定在一個固定的抽象層次上。

● 優秀的擴充能力

看看我們的例子，想增加實作？沒問題！想增加抽象，也沒有問題！隻要對外暴露的接口層允許這樣的變化，我們已經把變化的可能性減到最小。

● 實作細節對客戶透明

客戶不用關心細節的實作，它已經由抽象層通過聚合關系完成了封裝。

使用場景：

● 不希望或不适用使用繼承的場景

例如繼承層次過渡、無法更細化設計顆粒等場景，需要考慮使用橋梁模式。

● 接口或抽象類不穩定的場景

明知道接口不穩定還想通過實作或繼承來實作業務需求，那是得不償失的，也是比較失敗的做法。

● 重用性要求較高的場景

設計的顆粒度越細，則被重用的可能性就越大，而采用繼承則受父類的限制，不可能出

現太細的顆粒度。

總結：

        繼承非常好，但是有缺點(比如"強侵入")，我們可以揚長避短，對于比較明确不發生變化的，則通過繼承來完成；若不能确定是否會發生變化的，那就認為是會發生變化，則通過橋梁模式來解決，這才是一個完美的世界。