1. 概述

　　將抽象部分（Abstraction）與實(shí)現(xiàn)部分（Implementor）分離，使它們可以獨(dú)立地變化。

2. 解決的問題　　

　　在軟件系統(tǒng)中，有些類型由于自身的邏輯，它具有兩個或多個維度的變化。為了解決這種多維度變化，又不引入復(fù)雜度，這就要使用Bridge模式。

3. 模式中的角色

　　2.1 抽象（Abstraction）：定義抽象接口，該接口中包含實(shí)現(xiàn)具體行為、具體特征的Implementor接口。

　　2.2 提煉的抽象（RefinedAbstraction）：繼承自Abstraction的子類，依舊是一個抽象的事物名。

　　2.3 實(shí)現(xiàn)（Implementor）：定義具體行為，具體特征的應(yīng)用接口。

　　2.4 具體實(shí)現(xiàn)（ConcreteImplementor）：實(shí)現(xiàn)Implementor。

4. 模式解讀

　　4.1 實(shí)現(xiàn)要點(diǎn)

　　　　Bridge模式使用“對象間的組合/聚合關(guān)系”解耦了抽象和實(shí)現(xiàn)之間固有的綁定關(guān)系，使得抽象和實(shí)現(xiàn)可以沿著各自的維度來變化

　　4.2 橋接模式的類圖　　

　　4.3 橋接模式的實(shí)現(xiàn)代碼

 /// <summary>
 /// 實(shí)現(xiàn)
 /// </summary>
 public abstract class Implementor
 {
  public abstract void Opration();
 }

 public class ConcreteImplementorA : Implementor
 {
  public override void Opration()
  {
   Console.WriteLine("具體實(shí)現(xiàn)A的方法執(zhí)行。");
  }
 }

 public class ConcreteImplementorB : Implementor
 {
  public override void Opration()
  {
   Console.WriteLine("具體實(shí)現(xiàn)B的方法執(zhí)行。");
  }
 }

 /// <summary>
 /// 抽象
 /// </summary>
 public abstract class Abstraction
 {
  protected Implementor implementor;

  public void SetImplementor(Implementor implementor)
  {
   this.implementor = implementor;
  }

  public abstract void Opration();
 }

 /// <summary>
 /// 被提煉的抽象
 /// </summary>
 public class RefinedAbstraction : Abstraction
 {
  public override void Opration()
  {
   implementor.Opration();
  }
 }

　　4.4 客戶端的調(diào)用

 class Program
 {
  static void Main(string[] args)
  {
   Abstraction abstraction = new RefinedAbstraction();

   abstraction.SetImplementor(new ConcreteImplementorA());
   abstraction.Opration();

   abstraction.SetImplementor(new ConcreteImplementorB());
   abstraction.Opration();

   Console.Read();
  }

 }

　　輸出結(jié)果：

　　具體實(shí)現(xiàn)A的方法執(zhí)行。
　　具體實(shí)現(xiàn)B的方法執(zhí)行。

5. 橋接模式是個比較復(fù)雜的模式，在對它總結(jié)之前，先看一個大家都非常熟悉的應(yīng)用：三層架構(gòu)　　

　　解讀：三層架構(gòu)中的業(yè)務(wù)邏輯層（LogicalTierInterface)橋接到了數(shù)據(jù)訪問層(DatabaseTierInterface)，大家可以比較一下這個圖和上面橋接模式的圖是多么的一致。大家往往會在數(shù)據(jù)庫訪問這端做擴(kuò)展，比如現(xiàn)在增加對MySql的支持；往往只對業(yè)務(wù)邏輯層的實(shí)現(xiàn)（LogicalImplement)做一些內(nèi)部修改，而不是擴(kuò)展一個新的實(shí)現(xiàn)。如果你的應(yīng)用確實(shí)需要對業(yè)務(wù)邏輯層做一個擴(kuò)展(比如NewLogicalImplement)，那么這個三層架構(gòu)對橋接模式的應(yīng)用就算是比較完整的了。

6. 模式總結(jié)

　　6.1 優(yōu)點(diǎn)

　　　　6.1.1 降低了沿著兩個或多個維度擴(kuò)展時的復(fù)雜度，防止類的過度膨脹。

　　　　6.1.2 解除了兩個或多個維度之間的耦合，使它們沿著各自方向變化而不互相影響

　　6.2 缺點(diǎn)

　　　　還未發(fā)現(xiàn)

　　6.3 適用場景

　　　　6.3.1 當(dāng)一個對象有多個變化因素時，可以考慮使用橋接模式，通過抽象這些變化因素，將依賴具體實(shí)現(xiàn)修改為依賴抽象。

　　　　6.3.2 當(dāng)我們期望一個對象的多個變化因素可以動態(tài)變化，而且不影響客戶端的程序使用時。

　　　　6.3.3 如果使用繼承的實(shí)現(xiàn)方案，會導(dǎo)致產(chǎn)生很多子類，任何一個變化因素都需要產(chǎn)生多個類來完成，就要考慮橋接模式。

以上就是本文的全部內(nèi)容，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論