適配器模式
故事的前因后果
在一個陽光明媚的上午，你剛坐好，然后該死的產品那邊又來需求了，“新增頁面展示本APP的用戶信息 ，要趕緊做好，明天就上線，怎么實現我不管”，真tm有句媽賣批必須要講！，?? 但是做還是要做的 ， 寫個接口先
public interface IUserInfo{ //得到用戶的姓名 public String getUserName(); //得到用戶的頭像 public String getHeadImage(); //得到用戶的郵箱 public String getUserEmail(); //得到用戶的手機號 public String getMobileNumber(); 。。。。}然后寫個實體類(此處省略變量聲明和seter geter)
public class Userinfo implements IUserInfo { @Override public String getUserName() { System.out.喲西，然后請求網絡解析玩這個之后直接在頁面顯示了，又可以偷偷的玩兩把王者農藥了。 正性質沖沖的準備玩呢，然后一封郵件發過來，一看是大boss ，說讓對接一個啥子閱讀第三方，他們的用戶信息也要能顯示在我們的APP上，看到那封郵件我的心情是這樣的阿西吧
畢竟人家是給你發工資的。。 低下驕傲的小頭顱看他們的文檔，，shit 數據結構一點都不對，對接個毛啊
public interface IOtherUserInfo { //獲取用戶基本信息 public Map<String, String> getUserLocalInfo(); //獲取用戶APP內活動信息 public Map<String, String> getUserAppInfo();}我曹了個DJ，這接毛線啊。我又轉眼一想，機制的我不能這小小的困難打?。?/p>
先寫個類繼承那邊過來的實體類 ， 也就是OtherUserInfo,然后就開始
嘿
嘿
嘿
public class OtherUser extends OtherUserInfo implements IUserInfo { @Override public String getUserName() { // 從getUserLocalInfo()里尋找自己想要的信息 return null; } @Override public String getHeadImage() { // 從getUserAppInfo()里尋找自己想要的信息 return null; } @Override public String getUserEmail() { // 從getUserLocalInfo()里尋找自己想要的信息 return null; } @Override public String getMobileNumber() { // 從getUserLocalInfo()里尋找自己想要的信息 return null; }}ye
搞定，這樣就完美運行在一起了
接著玩我的王者農藥去了、、
是時候來一波總結了
剛剛用的就是適配器模式，從上面來看，適配器模式就是：
將一個類的接口變換成客戶端所期待的另一種接口，從而使原本因接口不匹配而無法再一起工作的兩個類能夠在一起工作
優點
可以讓兩個沒有任何關系的類在一起運行，只要適配器這個角色能夠搞定他們增加了類的透明度和靈活性提高了類的復用成都適用場景
有動機修改一個已經投產中的接口注意
在詳細設計的時候不要考慮他，他不是為了解決還處在開發階段的問題
新聞熱點
疑難解答
