适配器模式是开发中经常会用到的模式,Android开发中经常用到的各种adapter就属于适配器模式,连接各种数据库时也要用到适配器模式。适配器模式在生活中的实例也随处可见,你托人在日本买了个电饭煲,日本的市电电压是110v,而国内的市电电压是220v,这时你若想安全的使用电饭煲就必须装一个220-110的变压器,这个变压器就可以理解成本模式中的适配器。
适配器模式有类的适配器模式和对象的适配器模式两种不同的形式。首先看一下类的适配器模式UML类图:
可以看到,目标接口中有方法1和方法2,而我们只有方法1,若想得到方法2,可以生成一个Adapter类。我们以上面讲到的生活中的例子为例,实现以下代码:
1.我们有的220v,也就是上图中对应的Adaptee:
package com.adapter.demo;
public class Apply220V {
public int get220V(){
return 220;
}
}
2.想要110v,这里有个110v的接口:
package com.adapter.demo;
public interface Apply110V {
int get110v();
}
3.我们想要110v电压就要实现这个接口:
package com.adapter.demo;
public class From220vTo110v extends Apply220V implements Apply110V {
/**
* 适配器
*/
@Override
public int get110v() {
return 110;
}
}
设计模式的思想,增加这个中间的适配器可以使你的程序更灵活,更能多变。如果每次改需求你都有想杀人的冲动,说明你的程序没有好的设计,也就是没有用好设计模式,说明你要重构了。
这时编写一个测试类:
package com.adapter.demo;
public class TestClass {
public static void main(String[] args) {
From220vTo110v from220vTo110v=new From220vTo110v();
System.out.println("输出电压:"+from220vTo110v.get110v());
}
}
运行如下:
对象的适配器模式
对象适配器模式不是使用继承关系连接到Adaptee,而是使用代理模式连接到Adaptee类。UML类图如下:
这里需要修改的是适配器类:
package com.adapter.demo;
public class From220vTo110v implements Apply110V {
/**
* 适配器
*/
Apply220V apply220v;
public From220vTo110v(Apply220V apply220v) {
this.apply220v=apply220v;
}
public int getApply220v() {
return apply220v.get220V();
}
@Override
public int get110v() {
return 110;
}
}
测试类:
package com.adapter.demo;
public class TestClass {
public static void main(String[] args) {
From220vTo110v from220vTo110v=new From220vTo110v(new Apply220V());
System.out.println("输出电压:"+from220vTo110v.get110v());
}
}
运行如下:
我们可以看出:类适配器使用对象继承的方式,是静态的定义方式;而对象适配器使用对象组合的方式,是动态组合的方式。对象适配器更为灵活。
对于类适配器,适配器可以重定义Adaptee的部分行为,相当于子类覆盖父类的部分实现方法。
对于对象适配器,要重定义Adaptee的行为比较困难,这种情况下,需要定义Adaptee的子类来实现重定义,然后让适配器组合子类。虽然重定义Adaptee的行为比较困难,但是想要增加一些新的行为则方便的很,而且新增加的行为可同时适用于所有的源。
最后:
设计模式是手段,不是目的,设计模式可以帮我们更好地理解他人的代码,同时也可以增加系统的可维护性、可扩展性、稳定性和灵活性。好的系统是需要设计的,设计模式就好像一个高手的内功一样,是需要修炼,需要融会贯通的。
学习设计模式的道路注定是抽象的、枯燥的,量变产生质变,也许坚持一下走过这个山口,下一个山口就是目的地了。
喜欢的朋友关注我和我的公众号。