與電源適配器類似,在適配器模式中引入了一個被稱爲適配器(Adapter)的包裝類,而它所包裝的對象稱爲適配者(Adaptee),即被適配的類。適配器的實現就是把客戶類的請求轉化爲對適配者的相應接口的調用。也就是說:當客戶類調用適配器的方法時,在適配器類的內部將調用適配者類的方法,而這個過程對客戶類是透明的,客戶類並不直接訪問適配者類。所以,適配器讓那些因爲接口不兼容而不能交互的類能夠一塊兒工做。java
適配器模式能夠將一個類的接口和另外一個類的接口匹配起來,而無須修改原來的適配者接口和抽象目標類接口。git
將一個接口轉換成客戶但願的另外一個接口,使接口不兼容的那些類能夠一塊兒工做,其別名爲包裝器(Wrapper)。適配器模式既能夠做爲類結構型模式,也能夠做爲對象結構型模式。算法
在對象適配器模式結構圖中包含以下幾個角色:數據庫
● Target(目標抽象類):目標抽象類定義客戶所需接口,能夠是一個抽象類或接口,也能夠是具體類。編程
● Adapter(適配器類):適配器能夠調用另外一個接口,做爲一個轉換器,對Adaptee和Target進行適配,適配器類是適配器模式的核心,在對象適配器中,它經過繼承Target並關聯一個Adaptee對象使兩者產生聯繫。設計模式
● Adaptee(適配者類):適配者即被適配的角色,它定義了一個已經存在的接口,這個接口須要適配,適配者類通常是一個具體類,包含了客戶但願使用的業務方法,在某些狀況下可能沒有適配者類的源代碼。app
Sunny 軟件公司 OA 系統須要提供一個加密模塊,將用戶機密信息(如口令、郵箱等)加密以後再存儲在數據庫中,系統已經定義好了數據庫操做類。爲了提升開發效率,現須要重用已有的加密算法,這些算法封裝在一些由第三方提供的類中,有些甚至沒有源代碼。試使用適配器模式設計該加密模塊,實如今不修改現有類的基礎上重用第三方加密方法。框架
結構圖設計以下:ide
代碼以下:測試
/** * Author: YiFan * Date: 2018/12/17 12:29 * Description: 數據庫操做接口 */ public interface IDataBaseOperation { /** * 用戶信息加密 * @param info 用戶口令、郵箱 * @return 加密後的用戶口令、郵箱 */ String informationEncryption(String info); } /** * Author: YiFan * Date: 2018/12/17 12:31 * Description: 適配者類 */ public class Adaptee { /** * 經過MD5算法加密用戶信息 * @param info 用戶口令、郵箱 * @return 加密的用戶口令、郵箱 */ public String informationEncryptionByMD5(String info) { return MD5Util.MD5(info); } } /** * Author: YiFan * Date: 2018/12/17 12:30 * Description: 適配器類 */ public class EncryptionAdapter implements IDataBaseOperation { private Adaptee adaptee; public EncryptionAdapter() { adaptee = new Adaptee(); } @Override public String informationEncryption(String info) { return adaptee.informationEncryptionByMD5(info); } } /** * Author: YiFan * Date: 2018/12/17 22:52 * Description: MD5加密算法 */ public class MD5Util { // MD5加密算法 public static String MD5(String key) { char hexDigits[] = { '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'A', 'B', 'C', 'D', 'E', 'F' }; try { byte[] btInput = key.getBytes(); // 得到MD5摘要算法的 MessageDigest 對象 MessageDigest mdInst = MessageDigest.getInstance("MD5"); // 使用指定的字節更新摘要 mdInst.update(btInput); // 得到密文 byte[] md = mdInst.digest(); // 把密文轉換成十六進制的字符串形式 int j = md.length; char str[] = new char[j * 2]; int k = 0; for (int i = 0; i < j; i++) { byte byte0 = md[i]; str[k++] = hexDigits[byte0 >>> 4 & 0xf]; str[k++] = hexDigits[byte0 & 0xf]; } return new String(str); } catch (Exception e) { return null; } } } /** * Author: YiFan * Date: 2018/12/17 22:42 * Description: 用戶類 */ public class User { // 用戶暱稱 private String nickname; // 用戶口令 private String password; // 用戶電話 private String tel; // 用戶郵箱 private String email; public String getNickname() { return nickname; } public void setNickname(String nickname) { this.nickname = nickname; } public String getPassword() { return password; } public void setPassword(String password) { this.password = password; } public String getTel() { return tel; } public void setTel(String tel) { this.tel = tel; } public String getEmail() { return email; } public void setEmail(String email) { this.email = email; } } /** * Author: YiFan * Date: 2018/12/17 12:34 * Description: 客戶端測試類 */ public class Client { public static void main(String[] args) { User user = new User(); user.setPassword("123456789"); user.setEmail("xyfaqq@163.com"); // 針對接口編程 IDataBaseOperation dataBaseOperation; // 實例化對象 dataBaseOperation = new EncryptionAdapter(); // 加密的用戶密碼 String passwordEncryption = dataBaseOperation.informationEncryption(user.getPassword()); // 加密的用戶郵箱 String emailEncryption = dataBaseOperation.informationEncryption(user.getEmail()); System.out.println("加密前用戶口令:" + user.getPassword() + ",加密後用戶口令:" + passwordEncryption); System.out.println("加密前用戶郵箱:" + user.getEmail() + ", 加密後用戶郵箱:" + emailEncryption); } }
直接結果爲:
加密前用戶口令:123456789,加密後用戶口令:25F9E794323B453885F5181F1B624D0B 加密前用戶郵箱:xyfaqq@163.com, 加密後用戶郵箱:B187339EF36A225D8A161790844BC8A1
適配器模式將現有接口轉化爲客戶類所指望的接口,實現了對現有類的複用,它是一種使用頻率很是高的設計模式,在軟件開發中得以普遍應用,在Spring等開源框架、驅動程序設計(如 JDBC 中的數據庫驅動程序)中也使用了適配器模式。
(1) 將目標類和適配者類解耦,經過引入一個適配器類來重用現有的適配者類,無須修改原有結構。
(2) 增長了類的透明性和複用性,將具體的業務實現過程封裝在適配者類中,對於客戶端類而言是透明的,並且提升了適配者的複用性,同一個適配者類能夠在多個不一樣的系統中複用。
(3) 靈活性和擴展性都很是好,經過使用配置文件,能夠很方便地更換適配器,也能夠在不修改原有代碼的基礎上增長新的適配器類,徹底符合「開閉原則」。
類適配器模式的缺點以下:
(1) 對於Java、C#等不支持多重類繼承的語言,一次最多隻能適配一個適配者類,不能同時適配多個適配者;
(2) 適配者類不能爲最終類,如在Java中不能爲final類,C#中不能爲sealed類;
(3) 在Java、C#等語言中,類適配器模式中的目標抽象類只能爲接口,不能爲類,其使用有必定的侷限性。
對象適配器模式的缺點以下:
與類適配器模式相比,要在適配器中置換適配者類的某些方法比較麻煩。若是必定要置換掉適配者類的一個或多個方法,能夠先作一個適配者類的子類,將適配者類的方法置換掉,而後再把適配者類的子類當作真正的適配者進行適配,實現過程較爲複雜。
(1) 系統須要使用一些現有的類,而這些類的接口(如方法名)不符合系統的須要,甚至沒有這些類的源代碼。
(2) 想建立一個能夠重複使用的類,用於與一些彼此之間沒有太大關聯的一些類,包括一些可能在未來引進的類一塊兒工做。