设计模式学习之适配器模式-方法与模式-火龙果软件

设计模式学习之适配器模式

来源：网络发布于： 2017-5-11

次浏览

在我们平时的开发过程中，适配器模式可以说是经常能见到的设计模式，ListView 和 RecyclerView 的 Adapter 就是典型的适配器模式，当我们在开发时，碰到要在两个完全没有关系的类之间进行交互，第一个解决方案是修改各自类的接口，但是如果无法修改源代码或者其他原因导致无法更改接口，此时怎么办？这种情况我们往往会使用一个 Adapter ，在这两个接口之间创建一个粘合剂接口，将原本无法协作的类进行兼容，而且不用修改原来两个模块的代码，符合开闭原则。

定义及使用场景

定义：适配器模式把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配无法在一起工作的两个类可以在一起工作。

使用场景：

1.系统需要使用现有的类，而此类的接口不符合系统的需要，即接口不兼容；

2.想要建立一个可以重复使用的类，用于与一些彼此之间没有太大联系的一些类，包括一些可能在将来引进的类一起工作；

3.需要一个统一的输出接口，而输入端的类型不可预知。

适配器模式从实现方式上分为两种，类适配器和对象适配器，这两种的区别在于实现方式上的不同，一种采用继承，一种采用组合的方式。

另外从使用目的上来说，也可以分为两种，特殊适配器和缺省适配器，这两种的区别在于使用目的上的不同，一种为了复用原有的代码并适配当前的接口，一种为了提供缺省的实现，避免子类需要实现不该实现的方法。

UML类图

适配器模式分为两种，即类适配器模式与对象适配器模式。以下是类适配器的UML图。

（1）Target：目标角色，也就是所期待得到的接口。注意：由于这里讨论的是类适配器模式，因此目标不可以是类。

（2）Adaptee：现在需要适配的接口。

（3）Adapter：适配器角色，也就是本模式的核心。适配器把源接口转换成目标接口。显然，这一角色不可以是接口，而必须是具体类。

适配器模式通用代码

类适配器模式

在上图中可以看出，Adaptee类并没有sampleOperation2()方法，而客户端则期待这个方法。为使客户端能够使用Adaptee类，提供一个中间环节，即类Adapter，把Adaptee的API与Target类的API衔接起来，Adapter与Adaptee是继承关系。

类的适配器模式把适配的类的API转换成为目标类的API

public interface Target {
/**
* 这是源类Adaptee也有的方法
*/
public void sampleOperation1();
/**
* 这是源类Adapteee没有的方法
*/
public void sampleOperation2();
}

上面给出的是目标角色的源代码，这个角色是以一个Java接口的形式实现的。可以看出，这个接口声明了两个方法：sampleOperation1()和sampleOperation2()。而源角色Adaptee是一个具体类，它有一个sampleOperation1()方法，但是没有sampleOperation2()方法。

public class Adaptee {

public void sampleOperation1(){}

}

适配器角色Adapter扩展了Adaptee,同时又实现了目标(Target)接口。由于Adaptee没有提供sampleOperation2()方法，而目标接口又要求这个方法，因此适配器角色Adapter实现了这个方法。

public class Adapter extends Adaptee implements Target {
/**
* 由于源类Adaptee没有方法sampleOperation2()
* 因此适配器补充上这个方法
*/
@Override
public void sampleOperation2() {
//写相关的代码
}

}

对象适配器模式

从上图可以看出，Adaptee类并没有sampleOperation2()方法，而客户端则期待这个方法。为使客户端能够使用Adaptee类，需要提供一个包装(Wrapper)类Adapter。这个包装类包装了一个Adaptee的实例，从而此包装类能够把Adaptee的API与Target类的API衔接起来。Adapter与Adaptee是委派关系，这决定了适配器模式是对象的。

public interface Target {
/**
* 这是源类Adaptee也有的方法
*/
public void sampleOperation1();
/**
* 这是源类Adapteee没有的方法
*/
public void sampleOperation2();
}

public class Adaptee {
public void sampleOperation1(){}

}

public class Adapter {
private Adaptee adaptee;
public Adapter(Adaptee adaptee){
this.adaptee = adaptee;
}
/**
* 源类Adaptee有方法sampleOperation1
* 因此适配器类直接委派即可
*/
public void sampleOperation1(){
this.adaptee.sampleOperation1();
}
/**
* 源类Adaptee没有方法sampleOperation2
* 因此由适配器类需要补充此方法
*/
public void sampleOperation2(){
//写相关的代码
}
}

类适配器和对象适配器的权衡

类适配器使用对象继承的方式，是静态的定义方式；而对象适配器使用对象组合的方式，是动态组合的方式。

1.对于类适配器，由于适配器直接继承了Adaptee，使得适配器不能和Adaptee的子类一起工作，因为继承是静态的关系，当适配器继承了Adaptee后，就不可能再去处理 Adaptee的子类了。

对于对象适配器，一个适配器可以把多种不同的源适配到同一个目标。换言之，同一个适配器可以把源类和它的子类都适配到目标接口。因为对象适配器采用的是对象组合的关系，只要对象类型正确，是不是子类都无所谓。

2.对于类适配器，适配器可以重定义Adaptee的部分行为，相当于子类覆盖父类的部分实现方法。

对于对象适配器，要重定义Adaptee的行为比较困难，这种情况下，需要定义Adaptee的子类来实现重定义，然后让适配器组合子类。虽然重定义Adaptee的行为比较困难，但是想要增加一些新的行为则方便的很，而且新增加的行为可同时适用于所有的源。

3.对于类适配器，仅仅引入了一个对象，并不需要额外的引用来间接得到Adaptee。

对于对象适配器，需要额外的引用来间接得到Adaptee。

建议尽量使用对象适配器的实现方式，多用合成/聚合、少用继承。当然，具体问题具体分析，根据需要来选用实现方式，最适合的才是最好的。

使用适配器模式克服观察者模式的缺点

观察者模式的一个缺点，即如果一个现有的类没有实现Observer接口，那么我们就无法将这个类作为观察者加入到被观察者的观察者列表中

举个例子，比如我们希望将HashMap这个类加到观察者列表里，在被观察者产生变化时，假设我们要清空整个map。但是Observable的观察者列表只认识Observer这个接口，它不认识HashMap，这种情况下，我们就可以使用类适配器的方式将我们的HashMap进行改造，类适配器采用继承的方式，那么我们写出如下适配器。

public class HashMapObserverAdapter<K, V> extends HashMap<K, V> implements Observer{

public void update(Observable o, Object arg) {
//被观察者变化时，清空Map
super.clear();
}

}

即我们继承我们希望复用其功能的类，并且实现我们想适配的接口，在这里就是Observer，那么就会产生一个适配器，这个适配器具有原有类（即HashMap）的功能，又具有观察者接口，所以这个适配器现在可以加入到观察者列表了。

然而类适配器的明显缺点就是JAVA单继承的限制，当我们要适配的对象是两个类的时候，我们是不可能用adapter继承两个类的，所以就有了组合模式。

例如，假设我们现在有一个user类

public class User extends BaseEntity{
private Integer id;
private String name;
public Integer getId() {
return id;
}
public void setId(Integer id) {
this.id = id;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}

我们可以看到User已经有了一个父类，此时假设我想使得User具有被观察者的功能那么User还要继承Observable类，这明显是不可能的，因为违反了单继承的原则。

那么，你可能会有这样的想法，那就是让User不继承BaseEntity，把BaseEntity里面的代码全部挪动到User类中，或者我不继承Observable了，把Observable里面的代码全部挪到User类里面。

但是做是非常糟糕的，比如我们项目要针对BaseEntity的子类进行一些统一的处理，这时候如果User没继承BaseEntity，那么你就会遗漏掉这个类，破坏继承体系。

如果你不继承Observable，而是把Observable里面的代码全部挪到User类里面，假设我现在不仅User类可以被观察了，我的Person类，Employee都能被观察了，那你就要把Observable的代码COPY三次到这三个类里面，无疑违反了代码复用的原则。

出于这样的考虑，我们采用对象适配器进行如下修改

//我们继承User,组合Observable.
public class ObservableUser extends User{

private Observable observable = new Observable();

public synchronized void addObserver(Observer o) {
observable.addObserver(o);
}

public synchronized void deleteObserver(Observer o) {
observable.deleteObserver(o);
}

public void notifyObservers() {
observable.notifyObservers();
}

public void notifyObservers(Object arg) {
observable.notifyObservers(arg);
}

public synchronized void deleteObservers() {
observable.deleteObservers();
}

protected synchronized void setChanged() {
observable.setChanged();
}

protected synchronized void clearChanged() {
observable.clearChanged();
}

public synchronized boolean hasChanged() {
return observable.hasChanged();
}

public synchronized int countObservers() {
return observable.countObservers();
}

}

为了维持项目中的继承体系，我们继承User，而不是继承Observable，另外如果想让ObservableUser具有User的属性，则需要将User的属性改为protected。

当然这里的写法也不是很好，因为我们要是还有Person,Employee类都要具有可观察的功能的话，那些Observable的方法我们还要再复制一遍。

于是我们又进行如下修改：

//我们扩展BaseEntity,适配出来一个可观察的实体基类
public class BaseObservableEntity extends BaseEntity{