適配器模式，這個模式也很簡單，你筆記本上的那個拖在外面的黑盒子就是個適配器，1般你在中國能用，在日本也能用，雖然兩個國家的的電源電壓不同，中國是 220V，日本是 110V，但是這個適配器能夠把這些不同的電壓轉換為你需要的 36V 電壓，保證你的筆記本能夠正常運行，那我們在設計模式中引入這個適配器模式是否是也是這個意思呢？是的，1樣的作用，兩個不同接口，有不同的實現，但是某1天突然上帝命令你把 B 接口轉換為 A 接口，怎樣辦？繼承，能解決，但是比較傻，而且還背背了 OCP 原則，怎樣辦？好在我們還有適配器模式。

適配器的通用類圖是這個模樣滴：

Target 是1個類（接口） ，Adaptee 是1個接口，通過 Adapter 把 Adaptee 包裝成 Target 的1個子類（實現類） ，注意了這里用了個名詞包裝（Wrapper） ，那其實這個模式也叫做包裝模式(Wrapper)，但是包裝模式可不知1個，還包括了以后要講的裝潢模式。我來說個自己的1個經驗，讓大家可以更容易了解這個適配器模式，否則純講技術太枯燥了，技術也能夠有文娛的嘛。

我在 2004 年的時候帶了1個項目，做1個人力資源管理，該項目是我們總公司發起的項目，公司1共有 700 多號人，包括子公司，這個項目還是比較簡單的，分為3大模塊：人員信息管理，薪酬管理，職位管理，其中人員管理這塊就用到了適配器模式，是怎樣回事呢？當時開發時明確的指明：人員信息簡管理的對象是所有員工的所有信息，然后我們就這樣設計了1個類圖：

還是比較簡單的，有1個對象 UserInfo 存儲用戶的所有信息（實際系統上還有很多子類，不多說了），也就是BO（Business Object） ，這個 UserInfo 對象，在系統中很多地方使用，你可以查看自己的信息，也能夠做修改，固然這個對象是有 setter 方法的，我們這里用不到就隱藏掉了。

這個項目是 04 年年底投產的，運行到 05 年年底還是比較安穩的，中間修修補補也很正常，05 年年底不知道是那股風吹的，很多公司開始使用借聘人員的方式招聘人員，我們公司也不例外，從1個人力資源公司借用了1大批的低技術、低工資的人員，分配到各個子公司，總共有將近 200 號人，然后就找我們部門老大談判，說要增加1個功能借用人員管理，老大1看有錢賺呀，1拍大腿，做！

我帶人過去1調研，不是這么簡單，人力資源公司有1套自己的人員管理系統，我們公司需要把我們使用到的人員信息傳輸到我們的系統中，系統之間的傳輸使用 RMI（Remote Method Invocation，遠程對象調用）的方式，但是有1個問題人力資源公司的人員對象和我們系統的對象不相同呀，他們的對象是這樣的：

人員資源公司是把人的信息分為了3部份： 基本信息， 辦公信息和個人家庭信息， 并且都放到了 HashMap中，比如人員的姓名放到 BaseInfo信息中，家庭地址放到 HomeInfo 中，這咱不好說他們系統設計的不好，那問題是咱的系統要和他們系統有交互，怎樣辦？使用適配器模式，類圖以下：

大家可能會問，這兩個對象都不在1個系統中，你如何使用呢？簡單！RMI 已幫我們做了這件事情，只要有接口，就能夠把遠程的對象當做本地的對象使用，這個大家有時間可以去看1下 RMI 文檔，不多說了。通過適配器，把 OuterUser 假裝成我們系統中1個 IUserInfo 對象，這樣，我們的系統基本不用修改甚么程序，所有的人員查詢、調用跟本地1樣樣的，說的口干舌燥，那下邊我們來看具體的代碼實現：

首先看 IUserInfo.java 的代碼：

然后看這個接口的實現類：

可能有人要問了，為何要把電話號碼、手機號碼都設置成 String 類型，而不是 int 類型，大家覺的呢？題外話，這個絕對應當是 String 類型，包括數據庫也應當是 varchar 類型的，手機號碼有小靈通帶區號的，比如 02100001，這個你用數字怎樣表示？有些人要在手機號碼前加上 0086 后再保存，比如我們公司的印度阿3就是這樣，喜歡在手機號碼前 0086保存下來，呵呵，我是想到啥就說啥，