设计模式之适配器模式（Java）

最近一直在研究设计模式的知识，通过自己的的学习和整理，今天跟大家分享的是适配器模式。

定义：

将一个接口转换成客户希望的另一个接口，适配器模式使接口不兼容的那些类可以一起工作，其别名为包装器(Wrapper)。适配器模式既可以作为类结构型模式，也可以作为对象结构型模式。

描述：

通常情况下，客户端可以通过目标类的接口访问它所提供的服务。有时，现有的类可以满足客户类的功能需要，但是它所提供的接口不一定是客户类所期望的，这可能是因为现有类中方法名与目标类中定义的方法名不一致等原因所导致的。

在这种情况下，现有的接口需要转化为客户类期望的接口，这样保证了对现有类的重用。如果不进行这样的转化，客户类就不能利用现有类所提供的功能，适配器模式可以完成这样的转化。

在适配器模式中可以定义一个包装类，包装不兼容接口的对象，这个包装类指的就是适配器(Adapter)，它所包装的对象就是适配者(Adaptee)，即被适配的类。

适配器提供客户类需要的接口，适配器的实现就是把客户类的请求转化为对适配者的相应接口的调用。也就是说：当客户类调用适配器的方法时，在适配器类的内部将调用适配者类的方法，而这个过程对客户类是透明的，客户类并不直接访问适配者类。因此，适配器可以使由于接口不兼容而不能交互的类可以一起工作。

结构：

• Target：目标抽象类
• Adapter：适配器类
• Adaptee：适配者类
• Client：客户类

适配器模式有对象适配器和类适配器两种实现：

对象适配器：

类适配器（由于Java不支持类的多继承，所以Java是不适用的）：

上面给出了适配器模式的UML简图，下面我们利用代码来说明适配器模式到底是什么样子的？又是如何去使用它的？

代码分析：

Target：

public interface Target {    void request();}

Adaptee：

public class Adaptee {    public void specificRequest(){        System.out.println("我是适配者");    }}

Adapter：

public class Adapter implements Target{    private Adaptee adaptee;    public Adapter(Adaptee adaptee){        this.adaptee = adaptee;    }    @Override    public void request() {        /**这里客户调用request()方法，实际上调用的是适配者的         *specificRequest()方法。所以达到了修改接口的目的         */        adaptee.specificRequest();    }}

Client：

public class Main {    public static void main(String[] args) {        Adaptee adaptee = new Adaptee();        Target target = new Adapter(adaptee);        target.request();    }}

通过以上我们发现，我们通过在不改变接口Target的情况下，通过适配器Adapter使用了Adaptee的功能。在这个过程中，我们并没有对Target做任何个修改。这就是我们要说的适配器模式。

下面我们来看看适配器模式都有哪些优缺点呢？

优点

• 将目标类和适配者类解耦，通过引入一个适配器类来重用现有的适配者类，而无须修改原有代码。
• 增加了类的透明性和复用性，将具体的实现封装在适配者类中，对于客户端类来说是透明的，而且提高了适配者的复用性。
• 灵活性和扩展性都非常好，通过使用配置文件，可以很方便地更换适配器，也可以在不修改原有代码的基础上增加新的适配器类，完全符合“开闭原则”。
• 一个对象适配器可以把多个不同的适配者适配到同一个目标，也就是说，同一个适配器可以把适配者类和它的子类都适配到目标接口。

缺点

• 想要置换适配者的方法不太容易。

我们说了适配器模式的优缺点，那么我们到底在什么情况下可以使用适配器模式呢？

• 系统需要使用现有的类，而这些类的接口不符合系统的需要。
• 想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作。