【设计模式】23种设计模式之适配器模式

23种设计模式之适配器模式

定义

将一个类的接口，转换成客户期望的另一个接口。适配器让原本不兼容的类可以合作无间。

UML类图

使用场景

有动机地修改一个正常运行的系统的接口，这时应该考虑使用适配器模式

实例

例子：客户调用鸭子接口，但现有系统没有鸭子接口，只有火鸡接口，需要将火鸡接口进行适配

目标接口

/**
 * 鸭子接口（目标接口）
 */
public interface Duck {
    void quack(); // 呱呱叫

    void fly(); // 飞行
}

/**
 * 绿头鸭
 */
public class MallardDuck implements Duck{
    @Override
    public void quack() {
        System.out.println("Quack!");
    }

    @Override
    public void fly() {
        System.out.println("I'm flying.");
    }
}

被适配者

/**
 * 火鸡接口(被适配者)
 */
public interface Turkey {
    void gobble(); // 咯咯叫

    void fly(); // 飞行
}

/**
 * 野生火鸡
 */
public class WildTurkey implements Turkey {
    @Override
    public void gobble() {
        System.out.println("Gobble.");
    }

    @Override
    public void fly() {
        System.out.println("I'm fly a short distance.");
    }
}

火鸡适配器

/**
 * 火鸡适配器：需要实现目标接口，存储适配对象的引用
 *
 * 通过该适配器，在客户调用鸭子接口，而我们现有接口的实现没有鸭子接口，只有火鸡接口，
 * 则可以通过适配器，使得对鸭子接口的调用，转换为对火鸡接口的调用，客户并不感知这一切
 */
public class TurkeyAdapter implements Duck {
    Turkey turkey; // 需要存储适配对象的引用

    public TurkeyAdapter(Turkey turkey) {
        this.turkey = turkey;
    }

    @Override
    public void quack() {
        turkey.gobble();
    }

    @Override
    public void fly() {
        // 火鸡飞行距离短，要想火鸡飞行距离和鸭子的一样，需要连续5次调用火鸡的fly函数
        for (int i = 0; i < 5; i++) {
            turkey.fly();
        }
    }
}

优缺点

优点：

1.让任何两个没有关联的类一起运行

2.提高了类的复用

3.增加了类的透明度

4.灵活性好

缺点：

1.过多地使用适配器，会让系统非常零乱，不易整体进行把握。比如，明明看到调用的是A接口，其实内部被适配成了B接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此如果不是很有必要，可以不使用适配器，而是直接对系统进行重构

2.由于 JAVA 至多继承一个类，所以至多只能适配一个适配者类，而且目标类必须是抽象类。

工作中的应用

项目中的适配层就是使用了适配器模式进行实现的，适配层可以将客户对旧版本的旧接口的调用，适配到当前版本的新的接口。对于客户侧而言，不需要做任何改变。

设计原则工具箱

1.找出应用中可能需要变化的部分，把它们独立出来，不要和那些不需要变化的代码混合在一起

2.针对接口（超类型）编程而不是针对具体的实现编程

3.多用组合少用继承

4.为了交互对象之间的松耦合设计而努力

5.类应该对扩展开放，对修改关闭

6.依赖抽象，不要依赖具体类。（即不要让高层组件依赖低层组件，而且不管高层组件还是低层组件都应该依赖于抽象）C](这里写自定义目录标题)