适配器模式

适配器模式

故事的前因后果

在一个阳光明媚的上午，你刚坐好，然后该死的产品那边又来需求了，“新增页面展示本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.print("mirsfang");
        return null;
    }

    @Override
    public String getHeadImage() {
        System.out.print("head");
        return null;
    }

    @Override
    public String getUserEmail() {
        System.out.print("mail");
        return null;
    }

    @Override
    public String getMobileNumber() {
        System.out.print("13712345678");
        return null;
    }
}

哟西，然后请求网络解析玩这个之后直接在页面显示了，又可以偷偷的玩两把王者农药了。 正性质冲冲的准备玩呢，然后一封邮件发过来，一看是大boss ，说让对接一个啥子阅读第三方，他们的用户信息也要能显示在我们的APP上，看到那封邮件我的心情是这样的

阿西吧

毕竟人家是给你发工资的。。 低下骄傲的小头颅看他们的文档，，shit 数据结构一点都不对，对接个毛啊

public interface  IOtherUserInfo {
    //获取用户基本信息
    public Map<String, String> getUserLocalInfo();
    //获取用户APP内活动信息
    public Map<String, String> getUserAppInfo();
}

我曹了个DJ，这接毛线啊。我又转眼一想，机制的我不能这小小的困难打败！

先写个类继承那边过来的实体类 ， 也就是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

搞定，这样就完美运行在一起了

接着玩我的王者农药去了、、

是时候来一波总结了

刚刚用的就是适配器模式，从上面来看，适配器模式就是：

将一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法再一起工作的两个类能够在一起工作

优点

• 可以让两个没有任何关系的类在一起运行，只要适配器这个角色能够搞定他们
• 增加了类的透明度和灵活性
• 提高了类的复用成都

适用场景

• 有动机修改一个已经投产中的接口

注意

在详细设计的时候不要考虑他，他不是为了解决还处在开发阶段的问题