思维盛宴之设计模式-适配器模式Adapter Pattern

适用场景示例

相信大家在软件开发工作中一定遇到过这样的情况：项目需要多个团队或成员合作开发，其中的某一个功能模块ClassA是由程序员A（或公司A）编写的，项目进行到一定阶段时由于需求渐变清晰，需要此模块提供一个对外通信的接口I，但在当时特定的场景下，这个模块并不方便进行改造甚至重写，它仅仅提供了较为接近所需接口功能的类，这时候，适配器模式就可以发挥作用啦~

适配器，Adapter, 顾名思义，便是对某一个事物做变化和更改，使其适配到我想要的样子。当A程序员编写了一个类或者接口，但这个接口并不完全符合我的需求时，我可以主动的将它变成我想要的接口I。那么问题来了，到底如何变化它呢？哈哈，用我的话说就是：要么”直接使唤“，要么”子承父业“！

通常，适配器模式分为两种形式：

1. 对象适配（“直接使唤”）
2. 类适配（“子承父业”）

简单说，对象适配通过直接包含要适配的类对象并加以干涉来改造其行为；类适配通过直接继承要适配的类来扩展其行为以达到目标需求。

---

实现(java)

我们来看一个具体的例子。现在要写一个小软件，我公司需要定义一个“工人”接口IWorker，实现“说话”，“工作”，“获得工资”等三个方法，但与我公司合作开发此软件的A公司由于其自身业务等特殊原因，仅仅提供了一个Person类，这个类只有“说话”，“睡觉”两个方法，鉴于公司“上层”压力，我们研发团队无法修改外部代码也无法指责A公司什么，所以团队经过内部讨论，一致决定自行解决此接口不匹配问题。

我们需要的工人接口：

public interface IWorker {
    void speak();
    void work();
    void getSalary();
}

A公司提供的类：

public class Person {

    public void speak(){
        System.out.println("I am a normal person.");
    }

    public void sleep(){
        System.out.println("Leave me alone.");
    }
}

使用对象适配模式改造：

public class WorkerObjectAdapter implements IWorker{

    Person person;    //直接包含待适配的对象来改造其行为

    public WorkerObjectAdapter(Person person) {
        this.person = person;
    }

    @Override
    public void work() {    //自行实现“work”行为
        System.out.println("work");
    }

    @Override
    public void getSalary() {    //自行实现“getSalary”行为
        System.out.println("get salary");
    }

    @Override
    public void speak() {    // 1. 改造“speak”行为
        person.speak();    //2. 直接使用待适配对象
        System.out.println("WorkerObjectAdapter speak");
    }

}

使用类适配模式改造：

public class WorkerClassAdapter extends Person implements IWorker{//继承待适配类

    @Override
    public void work() {    //自行实现“work”行为
        System.out.println("work");
    }

    @Override
    public void getSalary() {    //自行实现“getSalary”行为
        System.out.println("get salary");
    }

    @Override
    public void speak() {    // 3. 改造“speak”行为
        super.speak();    //4. 使用父类对象，即待适配对象
        System.out.println("WorkerClassAdapter speak");
    }

}

通过以上方式，我们研发团队重新将项目开发的主动权掌握在自己手中，将外部人员（A公司）的负面影响最小化（只有以上2,4处才会有风险）甚至可以通过异常处理等方式直接屏蔽掉风险，因为具体的适配器，实现所需接口的代码全是我们自己编写的嘛~大家都开心了，世界就和谐了~

适配器模式：我的地盘我做主！

---

转载请注明：