這幾天一直在研究各種各樣的設計模式，在學習適配器模式、橋接模式和外觀模式模式的時候，發現他們之間存在着一定的關係，實際上模式不適單一存在的，在我們的現實編程生活中往往是幾種模式結合使用的。
1．適配器模式與橋接模式的區別和聯繫
適配器模式和橋接模式都是間接引用對象，因此可以使系統更靈活，在實現上都涉及從自身以外的一個接口向被引用的對象發出請求。
兩種模式的區別在於使用場合不同，適配器模式主要解決兩個已有接口間的匹配問題，這種情況下被適配的接口的實現往往是一個黑匣子。我們不想，也不能修改這個接口及其實現。同時也不可能控制其演化，只要相關的對象能與系統定義的接口協同工作即可。適配器模式經常用在與第三方產品的功能集成上，採用該模式適應新類型的增加的方式是開發針對這個類型的適配器，如下所示。
橋接模式則不同，參與橋接的接口是穩定的，用戶可以擴展和修改橋接中的類，但是不能改變接口。橋接模式通過接口繼承或者繼承實現功能擴展，如圖所示。
按照GOF的說法，橋接模式和適配器模式用於設計的不同階段，橋接模式用於設計的前期，即在設計類時將類規劃爲邏輯和實現兩個大類，使它們可以分別進行演化；而適配器模式用於設計完成之後，當發現設計完成的類無法協同工作時，可以採用適配器模式。
然而，很多情況下在設計初期就要考慮適配器模式的使用，如涉及大量第三方應用接口的情況。
2．適配器模式與橋接模式的聯合
在實際應用中，橋接模式經常和適配器模式同時出現，如圖所示。本文給出一些示例，僅供參考。
這種情況經常出現在需要其他系統提供實現方法時，一個典型的例子是工業控制中的數據採集。不同工控廠家提供的底層數據採集接口通常不同，因此在做上層軟件設計時無法預知可能遇到何種接口。爲此需要定義一個通用的採集接口，然後針對具體的數據採集系統開發相應的適配器。數據存儲需要調用數據採集接口獲得數據，而數據可以保存到關係數據庫、實時數據庫或者文件中。數據存儲接口和數據採集結構構成了橋接，如圖所示。
同樣的結構也經常出現在報表相關的應用中，報表本身結構和報表輸出方式完全可以分開，如下圖所示。
報表輸出可以單獨抽象出來與報表的具體形式分開。但報表輸出又依賴於具體的輸出方式，如果需要輸出爲PDF格式，則要調用與PDF相關的API，而這是設計所無法控制的，因此這裏要使用適配器模式。
3．適配器模式與外觀模式的關係
適配器模式與外觀模式有些相似，都是對現相存系統的封裝。但這兩種模式的意圖完全不同，前者使現存系統與正在設計的系統協同工作而後者則爲現存系統提供一個更爲方便的訪問接口。簡單地說，適配器模式爲事後設計，而外觀模式則必須事前設計，因爲系統依賴於外觀。總之，適配器模式沒有引入新的接口，而外觀模式則定義了一個全新的接口。
適配器模式用於粒度較小的功能集成，如使用權威單位所規定的無法修改並替換的現有算法模塊（油罐的容積算法爲國家計量權威單位所規定，需要使用特定的模塊），將來也可能升級。這時可以使用適配器模式。
外觀模式的使用有時比較難把握，外觀接口的定義與設計人員對業務的理解程度有很大關係。如果接口設計過於複雜，則不如直接調用原系統簡單；如果接口設計過於簡單，有些功能需要調用原有系統才能實現，同樣達不到封裝目的。在這種情況下，首先要考慮被封裝系統的穩定程度。如果系統處於演化階段，那麼接口定義需要複雜一些，以暴露更多的接口。這時，外觀模式更像一個大粒度的適配器。被封裝系統發生演化時，需要新的外觀對象，而這個外觀對象起到了適配器的作用。下圖所示爲這種情況下的結構。
4．總結
我們討論了適配器模式、橋接模式和外觀模式之間的關係。適配器模式經常用在需要與第三方API協同工作的場合，在功能集成需求越來越多的今天，這種模式的使用頻度越來越高，特別是橋接模式與適配器的組合在設計中越來越頻繁地出現，幾乎已經成爲一種新的模式。
外觀模式是另一個在系統演化中常用的模式，在某些情況下，它與適配器模式的作用有些相似。但總體上來說，外觀模式所針對的對象粒度更大。