1：舊的硬碟和電源
小李有一台老的台式電腦，硬碟實在是太小了，僅僅40gb，但是除了這個問題外，整機效能還不錯，廢棄不用太可惜了，於是決定去加裝一塊新的硬碟。
在裝機公司為小李的電腦加裝新硬碟的時候，小李也在邊上**，順便了解點硬體知識。很快的，裝機人員把兩塊硬碟都安裝好了，細心的小李發現，這兩塊硬碟的連線方式是不一樣的。
經過裝機人員的耐心講解，小李搞清楚了它們的不同。以前的硬碟是串列埠的，如圖4.1，電腦電源如圖4.2，那麼連線電源的時候是直接連線。
2：加入新的硬碟
但是現在的新硬碟是並口的，如圖4.3，電源的輸出口無法直接連線到新的硬碟上了，於是就有了轉接線，一邊和電源的輸出口連線，一邊和新的硬碟電源輸入口連線，解決了電源輸出介面和硬碟輸入介面不匹配的問題，如圖4.4
3：有何問題
如果把上面的問題抽象一下，用物件來描述，那就是：有乙個電源類和舊的硬碟類配合工作得很好，現在又有了乙個新的硬碟類，現在想讓新的硬碟類和電源類也配合使用，但是發現它們的介面無法匹配，問題就產生了：如何讓原有的電源類的介面能夠適應新的硬碟類的電源介面的需要呢？
4：如何解決
解決方法是採用乙個轉接線類，轉接線可以把電源的介面適配成為新的硬碟所需要的介面，那麼這個轉接線類就類似本章的主角——介面卡。
看了上面這個例子，估計對介面卡模式有一點感覺了。這是個在生活中常見的例子，類似的例子很多，比如：各種管道的轉接頭、不同制式的插座等等。但是這種例子只能幫助大家理解介面卡模式的功能，跟實際的應用系統開發總是有那麼些差距，會感覺到好像是理解了模式的功能，但是一到真實的系統開發中，就不知道如何使用這個模式了，有些隔靴搔癢的感覺。因此，下面還是以實際系統中的例子來講述，以幫助大家真正理解和應用介面卡模式。
考慮乙個記錄日誌的應用，由於使用者對日誌記錄的要求很高，使得開發人員不能簡單的採用一些已有的日誌工具或日誌框架來滿足使用者的要求，而需要按照使用者的要求重新開發新的日誌管理系統。當然這裡不可能完全按照實際系統那樣去完整實現，只是抽取跟介面卡模式相關的部分來講述。
1：日誌管理第一版
在第一版的時候，使用者要求日誌以檔案的形式記錄。開發人員遵照使用者的要求，對日誌檔案的訪問實現如下。
（1）先簡單定義日誌物件，也就是描述日誌的物件模型，由於這個物件需要被寫入檔案中，因此這個物件需要序列化，示例**如下：
/*** 日誌資料物件
*/public class logmodel implements serializable
public void setlogid(string logid)
public string getoperateuser()
public void setoperateuser(string operateuser)
public string getoperatetime()
public void setoperatetime(string operatetime)
public string getlogcontent()
public void setlogcontent(string logcontent)
public string tostring()
}（2）接下來定義乙個操作日誌檔案的介面，示例**如下：
/*** 日誌檔案操作介面
*/public inte***ce logfileoperateapi
（3）實現日誌檔案的訪問，現在的實現也很簡單，就是讀寫檔案，示例**如下：
/*** 實現對日誌檔案的操作
*/public class logfileoperate implements logfileoperateapi
}public listreadlogfile()
} catch (exception e) finally
} catch (ioexception e)
}return list;
}public void writelogfile(listlist) catch (ioexception e) finally catch (ioexception e) }}
}（4）寫個客戶端來測試一下，看看好用不，示例**如下：
public class client
}測試的結果如下：
readlog=[logid=001,operateuser=admin,operatetime=2010-03-02 10:08:18,logcontent=這是乙個測試]
至此就簡單的實現了使用者的要求，把日誌儲存到檔案中，並能從檔案中把日誌內容讀取出來，進行管理。
看上去很容易，對吧，別慌，接著來。
2：日誌管理第二版
使用者使用日誌管理的第一版一段時間過後，開始考慮公升級系統，決定要採用資料庫來管理日誌，很快，按照資料庫的日誌管理也實現出來了，並定義了日誌管理的操作介面，主要是針對日誌的增刪改查方法，介面的示例**如下：
/*** 定義操作日誌的應用介面，為了示例的簡單，只是簡單的定義了增刪改查的方法
*/public inte***ce logdboperateapi
對於使用資料庫來儲存日誌的實現，這裡就不去涉及了，反正知道有這麼乙個實現就可以了。
客戶提出了新的要求，能不能讓日誌管理的第二版，實現同時支援資料庫儲存和檔案儲存兩種方式？
有朋友可能會想，這有什麼困難的呢，兩種實現方式不是都已經實現了的嗎，合併起來不就可以了？
問題就在於，現在的業務是使用的第二版的介面，直接使用第二版新加入的實現是沒有問題的，第二版新加入了儲存日誌到資料庫中；但是對於已有的實現方式，也就是在第一版中採用的檔案儲存的方式，它的操作介面和第二版不一樣，這就導致現在的客戶端，無法以同樣的方式來直接使用第一版的實現，如下圖4.5所示：
圖4.5 無法相容第一版的介面示意圖
這就意味著，要想同時支援檔案和資料庫儲存兩種方式，需要再額外的做一些工作，才可以讓第一版的實現適應新的業務的需要。
可能有朋友會想，乾脆按照第二版的介面要求重新實現乙個檔案操作的物件不就可以了，這樣確實可以，但是何必要重新做已經完成的功能呢？應該要想辦法復用，而不是重新實現。
一種很容易想到的方式是直接修改已有的第一版的**。這種方式是不太好的，如果直接修改了第一版的**，那麼可能會導致其它依賴於這些實現的應用不能正常執行，再說，有可能第一版和第二版的開發公司是不一樣的，在第二版實現的時候，根本拿不到第一版的源**。
那麼該如何來實現呢？
介面卡模式（類介面卡 物件介面卡）
做個筆記 引用 public inte ce usb public inte ce psp public class usber implements usb 類介面卡 psp適用usb介面 public class usbadapter extends usber implements psp 物...
介面卡模式 預設介面卡，類介面卡，物件介面卡
模式思想 改變乙個類的對外介面 增加或減少 以滿足不同外部呼叫者的需求 角色成員 目標介面 target 客戶所期待的介面。目標可以是具體的或抽象的類，也可以是介面。需要適配的類 adaptee 需要適配的類或適配者類。介面卡 adapter 通過包裝乙個需要適配的物件，把原介面轉換成目標介面。適配...
設計模式 介面卡模式 類介面卡 物件介面卡
乙個小例子，便於理解，上 這是我們造的。現在想用這個方法。public class adaptee 類介面卡。對我們想要的方法封裝一下，target就能像之前一樣，呼叫request方法即可。public class adapter1 extends adaptee implements targe...