把一个类的接口变换成客户端所期待的另一种接口,从而使原来因接口不匹配而无法在一起工作的两个类能够在一起工作。
适配器有三种模式:
类适配器:(采用继承实现)
类适配器是通过继承类适配者类(Adaptee Class)实现的,另外类适配器实现客户类所需要的接口。当客户对象调用适配器类方法的时候,适配器内部调用它所
继承的适配者的方法。(当客户在接口中定义了他期望的行为时,我们就可以应用适配器模式,提供一个实现该接口的类,并且扩展已有的类,通过创建子类来实现适配。)
对象适配器:(采用对象组合方式实现)
对象适配器包含一个适配器者的引用(reference),与类适配器相同,对象适配器也实现了客户类需要的接口。当客户对象调用对象适配器的方法的时候,对象适配器调它
所包含的适配器者实例的适当方法。(对象适配器”通过组合除了满足“用户期待接口”还降低了代码间的不良耦合。在工作中推荐使用“对象适配”。 )
类适配器示例:
3.5的接口的耳机在你手机上本来是没法使用的,因为它没有按照2.5接口的设计啊,而现在我又想使用这幅耳机,于是乎有了“适配器(Adapter)”这个一个东西出来了。
类的适配器类图:
以问题中例子为模型
目标抽象角色(Target):定义客户所期待要使用的接口,我们把手机当做客户端,客户端所需要使用的耳机的接口是2.5的,在这里就可以抽象出来一个2.5接口的设备(并不一定是耳机)。
源角色(Adaptee):需要被适配的接口,在这里指的是我们从市场上买回来的那个3.5接口的耳机。
适配器角色(Adapter):用来把源接口转换成符合要求的目标接口的设备,在这里指的是老板送给我们的那个“转换器”。
客户端(Client):这里指的就是那个给我们带来麻烦的手机喽。
Target.java对象的适配器模式:
对象的适配器模式的不同之处在于Adapter角色封装了Adaptee角色,而不像类的适配器模式所采取的继承方式。其原理基本上是相似的。
对象的适配器示例:
/**
* 该类拥有客户端所需要的业务逻辑,但是,由于客户端接受的是CustomerStyle类型的对象,
* 而不接受该类型的对象,所以无法直接将该类用于客户端
*/
public class Adaptee {
// 客户端需要用到的业务逻辑
public void methodA() {
System.out.println("我是被适配的类。");
}
}
/**
* 此接口是客户端调用时,所需要的格式,也就是说,客户端只接受该接口的实现类对象
*/
public interface CustomerStyle {
public void methodB ();
public void methodA ();
}
/**
* 适配器类,该类将实现CustomerStyle接口,成为其实现类(这样就可以在客户端被调用了),同时
* 合成源类,得到其具体业务逻辑。
*/
public class Adapter implements CustomerStyle{
private Adaptee adaptee;
public Adapter (Adaptee adaptee) {
this.adaptee = adaptee;
}
/**
* 通过委派的对象,得到源类中的业务逻辑
*/
@Override
public void methodA() {
adaptee.methodA();
}
@Override
public void methodB() {
}
}
public class Main {
public static void main (String [] args) {
Adaptee adaptee = new Adaptee();
// 客户端只能接收该类(CustomerStyle接口的实现类)
Adapter adapter = new Adapter(adaptee);
adapter.methodA();
}
}
应用适配器模式的场景:
1.系统需要使用现有的类,而现有类不符合当前系统的要求。如问题的提出。
2.系统要建立一个可以重复使用的类,用来与彼此没有太大关联的类或者在将来要引用的类一起工作。