适配器设计模式

在学习SpringMVC框架时，看到源码中使用了适配器设计模式，不学习一下这种设计模式还真是看不懂源码了。经过一个上午的学习写下了这篇文章，用以记录。

 

适配器设计模式能解决什么问题？
 

答：使得原本由于接口不兼容不能在一起工作、不能统一管理的类可以在一起工作、可以进行统一管理。

举例解释

有三个工种，教师，程序员，厨师、他们分别有着与其工作相关的方法， teach(), program(), cook() 。

 

有对应的接口  ：  Teacher ， Programmer , Cooker

接口中的方法  ：  teach() , program() , cook()

有对应的实现类 ：TeacherImpl , ,ProgrammerImpl , CookerImpl

 

需求：打印出这三个工种所做的工作内容。

不使用适配模式的时候，可以这样写：

  

 

这样写的缺点是：要知道每一个接口里面指定的方法。

为了解决这个问题，我们先使用一种单个适配器的模式（目的是：引出多适配器）

 

单个适配器：
单个适配器类似于工具类，其提供了一个方法 work(Object worker) ,根据传进来的worker类型调用对应的方法。

这样就不需要知道每一个接口内部都写了什么方法了。

1.适配器接口：

2.实现类

3.测试类

 

 

单个适配器不需要再去了解每个接口内都写了什么方法了，只需要统一调用work()就可以实现需求了。
但是单个适配器的缺点 ： 如果增加了新的工种，需要修改适配器实现类，如果增加了一百种，一千种呢？所以这不是解决问题的方法。
 

多个适配器：
使用单个适配器的问题已经说过了，怎么去解决呢？ 答案就是使用多适配器，如果每一个工种都有对应的适配器接口实现类的话，就可以通过统一管理对应的适配器接口实现类（因为都实现了相同的接口，所以可以统一管理），进而统一管理不同的工种，大致思路为：

1.为每一个工种都建立一个对应的适配器接口实现类，实现类中调用对应工种的方法。

2.在使用时，需要先获取到所有的适配器，然后遍历需求中给出的所有的工人，再嵌套循环遍历每一个适配器，找出与传入工人对应的适配器（因为这个需求，所以在适配器接口中应该有一个boolean isSupport( Object worker)方法，来判断这个适配器是否支持传入的worker），找到对应的适配器后，调用work()方法就实现了统一管理。

代码：
1.适配器接口
    

2.不同工种对于适配器的的实现
    
    
    

3.测试类
    

多个适配器的缺点：需要为每一个工种添加一个适配器

 

 

 适配器模式：将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。 
 适配器模式有类适配器模式和对象适配器模式两种不同的形式。

类适配器 
 类适配器模式把适配的类的API转换成目标类的API 
 
 适配器模式所涉及的角色：

目标角色（Target）： 这就是所期待得到的接口。
源角色（Adaptee）：需要适配的接口
适配器角色（Adapter）：适配器类是本模式的核心。适配器把源接口转换成目标接口。显然，这一角色不可以是接口，而必须是具体类。
举个简单例子： 
1 目标角色

public interface Target
{
    public void request();
}
1
2
3
4
2 源角色

public class Adaptee
{
    public void specificRequest()
    {
        System.out.println("被适配的类Adaptee");
    }
}
1
2
3
4
5
6
7
3 适配器角色（类适配器决定了Target不能为类，只能为接口，因为java不支持多继承的关系）

public class Adapter extends Adaptee implements Target
{
    @Override
    public void request()
    {
        super.specificRequest();
    }
}
1
2
3
4
5
6
7
8
4 测试代码

        Target adapter = new Adapter();
        adapter.request();
1
2
对象适配器 
举个简单例子

目标角色（同上，这里的目标角色Target可以为类）
源角色（同上）
适配器角色
public class ObjectAdapter implements Target
{
    private Adaptee adaptee;

    public ObjectAdapter(Adaptee adaptee)
    {
        this.adaptee = adaptee;
    }

    @Override
    public void request()
    {
        this.adaptee.specificRequest();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
4.测试代码：

        Target adapter = new ObjectAdapter(new Adaptee());
        adapter.request();
1
2
类适配器和对象适配器的权衡

类适配器使用对象集成的方式，是静态的定义方式；而对象适配器使用对象组合的方式，是动态组合的方式。
对于类适配器，由于适配器直接继承了Adaptee，使得适配器不能和Adaptee的子类一起工作，因为继承是静态的关系，当适配器继承了Adaptee后，就不能再取处理Adaptee的子类了。对于对象适配器，一个适配器可以把多种不同的源适配到同一个目标。换言之，同一个适配器可以把源类和它的子类都适配到目标接口。因为对象适配器采用的是对象组合的关系，只要对象类型正确，是不是子类都无所谓。
对于类适配器，适配器可以重定义Adaptee的部分行为，想当于子类覆盖父类的部分实现方法。对于对象适配器，要重定义Adaptee的行为比较困难，这种情况下，需要定义Adaptee的子类来实现重定义，然后让适配器组合子类。虽然重定义Adaptee的行为比较困难，但是想要增加一些新的行为则方便的很，而且新增加的行为可同时适用于所有的源。
对于类适配器，仅仅引入了一个对象，并不需要额外的引用来间接得到Adaptee，对于对象适配器，需要额外的引用来间接得到Adaptee。 
总结：建议尽量使用对象适配器的实现方式，符合CARP原则。
Jdk中的适配器模式 
java.util.Arrays#asList() 
java.io.InputStreamReader(InputStream) 
java.io.OutputStreamWriter(OutputStream)

总结 
 优点：更好的复用性：系统需要使用现有的类，而此类的接口不符合系统的需要。那么通过适配器模式就可以让这些功能得到更好的复用。更好的扩展性：在实现适配器功能的时候，可以调用自己开发的功能，从而自然地扩展系统的功能。 
 缺点：过多的使用适配器，会让系统非常零乱，不易整体进行把握。如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。

适用场景

你想使用一个已经存在的类，而它的接口不符合你的需求
你想创建一个可以复用的类，该类可以与其他不相关的类或不可预见的类协同工作。
（仅使用与对象Adapter）你想使用一些已经存在的子类，但是不可能对每一个都进行子类化以匹配它们的接口。
默认适配器 
 当你想实现一个接口但又不想实现接口中所有的方法，只想去实现一部分方法时，就用到了默认适配器模式。它的方法时在接口和具体实现类中添加一个抽象类，而用抽象类是实现目标接口的所有方法。而具体的实现类只需要覆盖其需要完成的方法即可。 
举个简单案例： 
1 接口类（有许多方法：吃，睡，工作以及锻炼，但是我懒只想吃喝睡）

public interface Live
{
    void sleep();
    void eat();
    void work();
    void train();
}

2 抽象类：

public class LiveDefault implements Live
{
    @Override public void sleep(){}

    @Override public void eat(){}

    @Override public void work(){}

    @Override public void train(){}
}
3 实现类

public class LiveImpl extends LiveDefault
{
    @Override
    public void eat()
    {
        System.out.println("哇塞，好好吃");
    }

    @Override
    public void sleep()
    {
        System.out.println("好困，就是不想起床");
    }
}

参考资料 
1. 《《JAVA与模式》之适配器模式》 
2. 《23种设计模式》 
3. 《Java模式(适配器模式)》 
4. 《细数JDK里的设计模式》