手机充电的电压为5V,而普通家用电的电压为220V,为了解决这种电压不兼容的问题,我们引入了电源适配器(俗称充电器)。在软件系统中,类与类,模块与模块之间也会出现类似不兼容的现象,这时我们需要引入适配器模式来解决这个问题。
与电源适配器相似,在适配器模式中引入了一个被称为适配器(Adapter)的包装类,它相当于我们的手机充电器,而它所包装的对象称为适配者(Adaptee),即被适配的类,它相当与我们家用的220V电。适配器的实现就是把客户端的请求转化为对适配者的相应接口的调用。也就是说,当客户类调用适配器的方法时,在适配器类内部将调用适配者类的方法,而这个过程对客户类是透明的,客户类并不直接访问适配者类。因此,适配者让那些由于接口不兼容而不能交互的类可以一起工作。
适配器模式可以将一个类的接口和另一个类的接口匹配起来,而无须修改原有的适配者接口和目标类接口。
适配器模式的定义如下:
适配器模式(Adapter Pattern):将一个接口转换成客户希望的另一个接口,使接口不兼容的那些类可以一起工作,其别名为包装器(Wrapper)。适配器模式既可以作为类结构型模式,也可以作为对象结构型模式。
注意:在适配器模式定义中所提及的接口是指广义的接口,它可以表示一个方法或者方法的集合。
根据适配器类与适配者类的关系不同,适配器模式可以分为对象适配器模式和类适配器模式两种。在对象适配器模式中,适配器与适配者之间是关联关系;在类适配器模式中,适配器与适配者之间是继承(或实现)关系。在实际开发中,对象适配器模式使用的频率更高,其UML图如下:
适配器模式主要包括一下3个角色:
1.Target(目标抽象类):目标抽象类定义客户所需接口,可以是一个抽象类或接口,也可以是具体类;
2.Adapter(适配器类):适配器可以调用另一个接口,作为一个转换器,对Adaptee和Target进行适配。适配器类是适配器模式的核心,在对象适配者模式中,它通过继承Target并关联一个Adaptee对象使二者产生联系;
3.Adaptee(适配者类):适配者即被适配的角色,它定义了一个已经存在的接口,这个接口需要适配,适配者类一般是一个具体类,包含客户希望使用的业务方法,在某些情况下可能没有适配者类的源代码。
在对象适配器模式中,客户端需要调用request()方法,而适配者类Adaptee没有该方法,但是它所提供的specificRequest()方法却是客户端所需要的。为了使客户端能够使用适配者类,需要提供一个包装类Adapter,即适配器类。这个包装类包装了一个适配者的实例,从而将客户端与适配者衔接起来,在适配器的request()方法中调用适配者的specificRequest()方法。因为适配器类与适配者类是关联关系(也可称之为委派关系),所以这种适配器模式称为对象适配器模式。其Java代码实现如下:
/**
* 目标类,客户端需要调用原接口的类(此接口与适配者类的接口即具体功能实现的接口不兼容)
*/
public interface Target {
//客户需要调用的接口
void request();
}
/**
* 适配者类,客户需要使用此类中的方法,但是此类中的方法与目标类的接口不兼容
*/
public class Adaptee {
public void specificRequest() {
System.out.println("客户最终要使用此方法");
}
}
/**
* 适配器类,通过对Adaptee类中客户需要使用的specificRequest方法的转换,来为客户提供兼容的request接口
*/
public class Adapter implements Target {
//维持一个对适配者对象的引用
private Adaptee adaptee;
public Adapter(Adaptee adaptee) {
this.adaptee = adaptee;
}
@Override
public void request() {
//真正调用客户端需要调用的方法
adaptee.specificRequest();
}
}
/**
* 客户端类
*/
public class Client {
public static void main(String[] args) {
//创建适配者对象
Adaptee adaptee = new Adaptee();
//创建客户端需要调用的目标对象,并注入真正需要调用的方法的对象
Target target = new Adapter(adaptee);
//通过目标类调用方法,内部真正调用的适配者对象的方法
target.request();
}
}
适配器模式的主要优点如下:
1.将目标类与适配者类解耦,通过引入一个适配器类来重用现有的适配者类,无须修改原有结构;
2.增加了类的透明性和复用性,将具体的业务实现过程封装在适配者类中,对于客户端类而言是透明的,而且提高了适配者类的复用性,同一个适配者类可以在多个不同的系统中复用;
3.灵活性和扩展性都非常好,通过使用配置文件,可以很方便地更换适配器,也可以在不修改原有代码的基础上增加新的适配器类,完全符合开闭原则。
适配器模式的主要缺点如下:
要在适配器中置换适配者类的某些方法比较麻烦。如果一定要置换掉适配者类的一个或多个方法,可以先做一个适配者类的子类,在子类中将适配者类的方法置换掉,然后再把适配者类的子类当作真正的适配者进行适配,实现过程较为复杂。
适配器模式的适用场景如下:
1.系统需要使用一些现有的类,而这些类的接口(例如方法名)不符合系统的需要,甚至没有这些类的源代码;
2.想创建一个可以重复使用的类,用于与一些彼此之间没有太大关联的类,包括一些可能在将来引进的类一起工作。