1. 概述

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

2. 解決的問題　　

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

3. 模式中的角色

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

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

　　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模式使用“對(duì)象間的組合/聚合關(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. 橋接模式是個(gè)比較復(fù)雜的模式，在對(duì)它總結(jié)之前，先看一個(gè)大家都非常熟悉的應(yīng)用：三層架構(gòu)　　

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

6. 模式總結(jié)

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

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

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

　　6.2 缺點(diǎn)

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

　　6.3 適用場(chǎng)景

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

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

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

以上就是本文的全部?jī)?nèi)容，希望能給大家一個(gè)參考，也希望大家多多支持我們。