接口适配器模式介绍:
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.组合服用原则:尽量不要用继承,而用合成/聚合,不满足。
总结:个人感觉这种模式可以用与一些小而多的功能,并且还可以自己定制,比较合适这种模式,如果别转换的复杂,就不能自己重写了就要用对象适配器模式,这个模式和策略也有那么点相似的味道,不过策略注重的还是策略,比用到什么算法,可以用策略,但是这种我觉还是用于以下小而简单的适配比较合适