橋接模式和介面卡模式的區別
很多時候經常容易把橋接模式和介面卡模式弄混。那什麼時候用橋接，什麼時候用介面卡呢 ？
共同點
橋接和介面卡都是讓兩個東西配合工作
不同點
出發點不同。
1）介面卡：改變已有的兩個介面，讓他們相容。
2）橋接模式：分離抽象化和實現，使兩者的介面可以不同，目的是分離。
所以說，如果你拿到兩個已有模組，想讓他們同時工作，那麼你使用的介面卡。
如果你還什麼都沒有，但是想分開實現，那麼橋接是一個選擇。
橋接是先有橋，才有兩端的東西
適配是先有兩邊的東西，才有介面卡
橋接是在橋好了之後，兩邊的東西還可以變化。
例如遊戲手柄，就象個橋，它把你的任何操作轉化成指令。
（雖然，你可以任何操作組合，但是你的操作脫不開山下左右，a,b，選擇 ，確定）
JRE本身就是一個就是一個很好的橋，先寫好在linux上執行的Jre，再寫好可以在windows下執行的JRE，
這樣無論什麼樣的Java程式，只要配和相應的Jre就能在Linux或者Windows上執行.
兩個Jre並沒有限定你寫什麼樣的程式，但要求你必須用Java來寫。
--------------------------------------------------------
在這篇文章中，我寫了Bridge和adapter模式的區別.但是
maninred說
Bridge和adapter是沒有關係的，而和Facade比較象，但在我的經驗中更多的時候
是會混淆Bridge和adapter而不是Facade，這裡詳細的列出三個模式的比較 .
一. 定義:
1. Facade模式是為一個複雜系統提供一個簡單的介面。比如你要去博物館參觀，很多東西，你一個個到處去問每個東西的管理員很麻煩，所以你找一個導遊，讓他給你一個個介紹，你只要找到導遊就好了。導遊就是門面。
2. 介面卡模式，引用一下GOF95中的話:
介面卡模式是把一個類的介面變換成客戶端所期待的另一種介面，從而使原本因介面不匹配而無法工作的兩個類能夠工作到一起。
舉個例子，例如變壓器
3. Bridge模式:
GOF95中的橋樑模式的描述：橋樑模式的用意是"將抽象化與實現化脫耦，使的二者可以獨立變化。
例如AWT的實現
二. 目的
1. Facade 模式使用在給一個複雜的系統提供統一的門面(介面),目的是簡化客戶端的操作,但並沒有改變介面.2. Adapter 模式使用在兩個部分有不同的介面的情況,目的是改變介面,使兩個部分協同工作
3. 橋接模式 是為了分離抽象和實現
二. 使用場合
1. Facade
出現較多是這樣的情況,你有一個複雜的系統,對應了各種情況,
客戶看了說功能不錯,但是使用太麻煩.你說沒問題,我給你提供一個統一的門面.
所以Facade使用的場合多是對系統的"優化".
2. Adapter
出現是這樣的情況,你有一個類提供介面A,但是你的客戶需要一個實現介面B的類,
這個時候你可以寫一個Adapter讓把A介面變成B介面,所以Adapter使用的場合是
指鹿為馬.就是你受夾板氣的時候,一邊告訴你我只能提供給你A(鹿),一邊告訴你說
我只要B(馬),他長了四條腿,你沒辦法了,把鹿牽過去說,這是馬,你看他有四條腿.
(當然實現指鹿為馬也有兩種方法,一個方法是你只露出鹿的四條腿,說你看這是馬,這種方式就是
封裝方式的Adapter實現,另一種方式是你把鹿牽過去,但是首先介紹給他說這是馬,因為他長了四條腿
這種是繼承的方式.)
3. Bridge
在一般的開發中出現的情況並不多,AWT是一個,SWT也算部分是,
如果你的客戶要求你開發一個系統,這個系統在Windows下執行介面的樣子是Windows的樣子.
在Linux下執行是Linux下的樣子.在Macintosh下執行要是Mac Os的樣子.
怎麼辦? 定義一系列的控制元件Button,Text,radio,checkBox等等.供上層開發者
使用,他們使用這些控制元件的方法,利用這些控制元件構造一個系統的GUI,然後你為這些控制元件
寫好Linux的實現,讓它在Linux上呼叫Linux本地的對應控制元件,
在Windows上呼叫Windows本地的對應控制元件,在Macintosh上呼叫Macintosh本地的對應控制元件
ok,你的任務完成了.
三. 需求程度
1. Facade的需求程度是 "中等" ,因為你不提供Facade程式照樣能工作,只是不夠好.2. Adapter的需求程度是 "必須" ,因為你不這麼做就不能工作,除非你自己從頭實現一個.
3. Bridge的需求程度是 "一般" ,適合精益求精的人,因為你可以寫三個程式給客戶.
四. 出現時期
1. Facade出現在專案中期,再優化2. Adapter出現在專案後期,大部分都有了,差的僅僅是介面不同
3. Bridge出現在專案前期,你想讓你的系統更靈活,更cool
五. 在寫文章的時候想到的
1. Facade很多時候是1:m的關係2. Adapter很多是候是1:1的關係
3. Bridge很多時候是m:n的關係
呵呵.
六. 最後
另外:迴應一下maninred1. 我並沒有把模式看的很獨立。
其實很多模式是配合使用的,而且在一定情況下可以
用一個替換另一個.同一個需求,有可能當你思考的角度不同時,使用的模式就不同了.
2. 設計模式並不是"用OO的封裝來封裝所有的東西"。
模式其實可以應用於所有的設計上和OO沒有直接的關係,只是因為計算機的設計模式大部分是GOF收集總結的,他們講解設計模式是用的C++,而在Java中得到了大量應用,所以我們談到設計模式的時候多提到OO.其真實模式更早應用於建築學,Alexander的《建築的永恆之道》講的就是設計模式。所以說設計模式應該是設計過程中積累下來的一些成型的東西。更深入一點，《Java與模式》的作者認為模式起源於中國的道教思想，講的是哲學。呵呵。
3. 對於模式的使用，個人感覺，模式很大程度上是為了對應這類需求的所有情況。
也就是最複雜情況，最靈活情況，當我們實際的開發中並沒有遇到這麼多這樣的情況。
所以在需要的時候使用，根據需求簡化使用，而不是照搬。
4. 雖然模式是相關的，但是隻有知道了每個模式的區別點，才能更好的根據需求選擇使用哪個模式。
轉載自：http://qinjs.blog.163.com/blog/static/23029492008123627012/