设计模式学习笔记十四：适配器模式

介绍

适配器（ADPATER）模式，也叫包装器（WRAPPER）模式，属于类对象结构型模式。是为了在现有功能类的基础上为客户提供匹配的接口。适配器有两种方式：对象适配器模式和类适配器模式，本文主要讲前者，后者会有单独的说明，因为个人不是很喜欢这种方式的调用。

意图：将一个类的接口转换成客户希望的另外一个接口。 Adapter模式使得原本由于接口不兼容

而不能一起工作的那些类可以一起工作（本段摘自《GoF设计模式》 4.1）。

适配器模式有几个要素：

目标接口：客户直接掉用的接口；

原始功能类：即被适配者，可以被复用的工具箱；

适配器：实现目标接口，引入原始功能类；

应用

电源适配器

高清转换头

spring-mybatis

适用场景

现有功能大部分都能够被新的需求复用。

UML结构图：

场景模拟

我是一家旅游网站，从事酒店出售业务。为了提高销售业绩，公司要把产品放到去哪儿网上出售，希望技术部门能实现对接。首先自营网站是有预定产品的所有相关实现的，那么开发人员要做的事情写更少、更优雅的代码完成任务。适配器就适合在这样的场景。

代码实现：

1.定义目标接口

/**
* 客户调用的目标接口
*/
public interface HotelTarget {
/**
* 还有没有房间
*/
boolean checkQuota(Integer roomId);

/**
* 预定房间
* @return
*/
boolean bookRoom(Integer roomId);
}

2.酒店适配器

/**
* 酒店适配器
*/
public class HotelAdapter implements HotelTarget {
private HotelBiz hotelBiz;
public HotelAdapter(HotelBiz hotelBiz) {
this.hotelBiz = hotelBiz;
}
/**
* 还有没有房间
*/
@Override
public boolean checkQuota(Integer roomId) {
return hotelBiz.getQuota(roomId) > 0;
}

/**
* 预定房间
*
* @return
*/
@Override
public boolean bookRoom(Integer roomId) {
return hotelBiz.bookRoom(roomId);
}
}

3.被适配者

/**
* 酒店业务逻辑类
*/
public class HotelBiz {
/**
* 剩余房间数
* @param roomId
* @return
*/
public int getQuota(Integer roomId) {
int quota = 1;
System.out.println("房间ID为" + roomId + "的配额 " + quota);
return quota;
}

/**
* 下订单
* @param roomId
* @return
*/
public boolean bookRoom(Integer roomId) {
System.out.println("房间ID是" + roomId + "的订单预定成功，入住日期：2015-07-28，离店日期：2015-08-01");
return true;
}
}

4.调用者

/**
* 目标客户
*/
public class Client {
public static void main(String[] args) {
HotelBiz hotelBiz = new HotelBiz();
HotelTarget target = new HotelAdapter(hotelBiz);
Integer roomId = 1234;
boolean hasRoom = target.checkQuota(roomId);
if (hasRoom) {
target.bookRoom(roomId);
}
}
}

5.输出

房间ID为1234的配额 1
房间ID是1234的订单预定成功，入住日期：2015-07-28，离店日期：2015-08-01

另一种实现方式

其实我们也可以直接继承HotelBiz类，这样同样也可以实现，并且代码量会少很多，这个模式就是类适配器模式。乍看来会比较简单，看事情复杂度不能完全以demo为例，demo只是为了达到表达目的对现实抽象到不能再抽象的实现而已，一个系统中不是一个类在工作。同时java中是不支持多继承的，想象一下如果要想达到继承多个类的效果会有多么的麻烦。受累、被鄙视都不是一个程序员希望的。

最后的告白

上述实现就是适配器的全部了，应该是很好理解。相信很多人在写代码时候都这么写过，只是有的人不知道这个玩意的“术语”而已。对，我也写过。写到最后发现这篇文章存在的价值是作为常见23种模式的一个成员，也是还了过去的技术债。

版权声明：本文为博主原创文章，未经博主允许不得转载。