.Net中適配器、橋接與外觀三模式的關係

1．適配器模式與橋接模式的區別和聯絡

　　適配器模式和橋接模式都是間接引用對象，因此可以使系統更靈活，在實現上都涉及從自身以外的一個介面向被引用的對象發出請求。

　 　兩種模式的區別在於使用場合不同，適配器模式主要解決兩個已有介面間的匹配問題，這種情況下被適配的介面的實現往往是一個黑匣子。我們不想，也不能修改 這個介面及其實現。同時也不可能控制其演化，只要相關的對象能與系統定義的介面協同工作即可。適配器模式經常用在與第三方產品的功能整合上，採用該模式適 應新類型的增加的方式是開發針對這個類型的適配器，如下所示。

　　橋接模式則不同，參與橋接的介面是穩定的，使用者可以擴充和修改橋接中的類，但是不能改變介面。橋接模式通過介面繼續或者繼續實現功能擴充，。

　　按照GOF的說法，橋接模式和適配器模式用於設計的不同階段，橋接模式用於設計的前期，即在設計類時將類規劃為邏輯和實現兩個大類，使它們可以分別進行演化；而適配器模式用於設計完成之後，當發現設計完成的類無法協同工作時，可以採用適配器模式。

      然而，很多情況下在設計初期就要考慮適配器模式的使用，如涉及大量第三方應用介面的情況。

　　2．適配器模式與橋接模式的聯合

　　在實際應用中，橋接模式經常和適配器模式同時出現，。本文給出一些樣本，僅供參考。

　 　這種情況經常出現在需要其他系統提供實現方法時，一個典型的例子是工業控制中的資料擷取。不同工控廠家提供的底層資料擷取介面通常不同，因此在做上層軟 件設計時無法預知可能碰到何種介面。為此需要定義一個通用的採集介面，然後針對具體的資料擷取系統開發相應的適配器。資料存放區需要調用資料擷取介面獲得數 據，而資料可以儲存到關聯式資料庫、即時資料庫或者檔案中。資料存放區介面和資料擷取結構構成了橋接，。

　　同樣的結構也經常出現在報表相關的應用中，報表本身結構和報表輸出方式完全可以分開，如所示。

　　報表輸出可以單獨抽象出來與報表的具體形式分開。但報表輸出又依靠於具體的輸出方式，假如需要輸出為PDF格式，則要調用與PDF相關的API，而這是設計所無法控制的，因此這裡要使用適配器模式。

　　3．適配器模式與面板模式的關係

　 　適配器模式與面板模式有些相似，都是對現相存系統的封裝。但這兩種模式的意圖完全不同，前者使現存系統與正在設計的系統協同工作而後者則為現存系統提供 一個更為方便的提供者。簡單地說，適配器模式為事後設計，而面板模式則必須事前設計，因為系統依靠於外觀。總之，適配器模式沒有引入新的介面，而外觀模 式則定義了一個全新的介面。

　　適配器模式用於粒度較小的功能整合，如使用權威單位所規定的無法修改並替換的現有演算法模組（油罐的容積演算法為國家計量權威單位所規定，需要使用特定的模組），將來也可能升級。這時可以使用適配器模式。

　 　面板模式的使用有時比較難把握，外觀介面的定義與設計人員對業務的理解程度有很大關係。假如介面設計過於複雜，則不如直接調用原系統簡單；假如介面設計 過於簡單，有些功能需要調用原有系統才能實現，同樣達不到封裝目的。在這種情況下，首先要考慮被封裝系統的穩定程度。假如系統處於演化階段，那麼介面定義 需要複雜一些，以暴露更多的介面。這時，面板模式更像一個大粒度的適配器。被封裝系統發生演化時，需要新的外觀對象，而這個外觀對象起到了適配器的作用。 所示為這種情況下的結構。

 
　　4．總結

　　我們討論了適配器模式、橋接模式和面板模式之間的關係。適配器模式經常用在需要與第三方API協同工作的場合，在功能整合需求越來越多的今天，這種模式的使用頻度越來越高，非凡是橋接模式與適配器的組合在設計中越來越頻繁地出現，幾乎已經成為一種新的模式。

      面板模式是另一個在系統演化中常用的模式，在某些情況下，它與適配器模式的作用有些相似。但總體上來說，面板模式所針對的對象粒度更大。