23种设计模式-适配器模式（接口适配器模式）

接口适配器模式介绍：
1.一些书籍称：适配器模式或缺省适配器模式。
2.当不需要实现接口提供的所有方法时，可以先设计一个抽象类是实现接口，并为该接口中的每一个方法提供一个模式实现（空方法），那么该抽象类的子类可有选择的覆盖父类的某些方法来实现需求。
3）适用于一个接口不想使用其所有的方法的情况

public interface Function {
    public int  Voltage220V();
    public int  Voltage110V();
    public int  Voltage30V();
    public int  Voltage5V();
}

public abstract class ChargerAdapter implements Function{
    public int Voltage220V() {
        return 0;
    }

    public int Voltage110V() {
        return 0;
    }

    public int Voltage30V() {
        return 0;
    }

    public int Voltage5V() {
        return 0;
    }
}

public class Client {
    public static void main(String[] args) {
        ChargerAdapter charger = new ChargerAdapter() {
            @Override
            public int Voltage5V() {
                return 5;
            }
        };
        System.out.println("用"+charger.Voltage5V()+"V开始充电！！！");
    }
}

回想适配器的三大角色：
1.目标角色（target）：这是客户锁期待的接口。目标可以是具体的或抽象的类，也可以是接口
2.适配者角色（adaptee）：已有接口，但是和客户器期待的接口不兼容。
3.适配器角色（adapter）：将已有接口转换成目标接口。
（疑问：实现接口的抽象类ChargerAdapter就是适配器，被适配者又是谁，难道是接口Function，所以这种接口叫适配器感觉有些牵强，这个ChargerAdapter像我们平常用的万能充电器，只要你把手机插入到这个充电器，他会根据电压去适应手机的电压，但是它在客户端又要重写方法，有感觉像一个什么功能都有的充电器，又要我们手动调整，感觉又像策略模式，自我改变充电策略，但是策略模式传入的是一个参数实现类，而这个传入的是抽象类实现类，重写抽象类的方法，暴露了实现过程，策略模式没有暴露实现过程。）

再回顾一下设计模式七大原则看看这个接口适配器模式有啥缺点：
1.单一职责原则：抽电器适配器类，也算单一职责，充电功能，只是每个充电方法不一样
2.接口隔离原则：实现了多余的方法，有点违背。
3.依赖倒转原则：用接口替代具体实体类，满足
4.里式替换原则：重写了父类的方法，违背，还是觉得对象适配器模式比较方便。
5.开遍原则：修改关闭，扩展开放，当客户需要用万能充电器时，只需要写个抽象父类的匿名内部类就实现，没有改到原来代码，扩展也符合
6.迪米特法则：虽然没有用局部变量，但是涌而来用了继承，并且可以随便重写父类的方法，没有满足最少知道的原则
7.组合服用原则：尽量不要用继承，而用合成/聚合，不满足。

总结：个人感觉这种模式可以用与一些小而多的功能，并且还可以自己定制，比较合适这种模式，如果别转换的复杂，就不能自己重写了就要用对象适配器模式，这个模式和策略也有那么点相似的味道，不过策略注重的还是策略，比用到什么算法，可以用策略，但是这种我觉还是用于以下小而简单的适配比较合适