设计模式之适配器模式

敲代码的哈士奇

已于 2022-06-25 22:46:07 修改

阅读量308

点赞数 2

分类专栏：设计模式文章标签：设计模式 java

于 2022-06-25 22:25:03 首次发布

本文链接：https://blog.csdn.net/manba_out/article/details/125464026

版权

设计模式专栏收录该内容

3 篇文章 0 订阅

订阅专栏

适配器模式特点及使用场景

适配器模式（Adapter）的定义如下：

将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。适配器模式分为类结构型模式和对象结构型模式两种，前者类之间的耦合度比后者高，且要求程序员了解现有组件库中的相关组件的内部结构，所以应用相对较少些。

适配器模式有三个角色：

target：目标角色，即当前业务场景所期望得到的接口

Adaptee：适配者角色，即需要去适配目标角色的接口

Adapter：适配器角色，相当于是一个转换器，将适配者接口转换成目标接口的类型

例如：我国标准电压为220V，普通的家用电器可以直接使用，而我的手机充电时需要用到充电器。原因是手机只支持5V、10V、11V等电压，此时手机充电器就相当于是适配器，手机支持的电压即target（目标角色），标准电压就是适配者，需要将220V的电压转换成10V的电压给手机充电（去适配手机支持的电压）。

适配器模式的优点如下：

在客户端可以透明的调用目标接口
可以复用原有的代码逻辑，不会对原有逻辑造成污染，如果日后不需要某个适配者，可以直接删除对应的接口而不会影响原有的代码逻辑
实现了目标类和适配者的解耦，可以完美解决目标接口和适配者接口的解耦

适配器模式的缺点如下：

在使用适配器模式的时候需要结合实际业务场景全面考虑，需要对业务较为熟悉
如果使用不当会使代码变得凌乱，可读性降低，增加了日后维护的难度

适用场景：

适配器模式不是在设计一个新功能的时候使用的设计模式，而是在对一个运行正常的功能进行扩展维护的时候使用的。

实际业务场景举例

我们的报销系统有一套默认的差旅费补助计算逻辑，且运行稳定，此时某个省市推出了一套新的差旅费补助方案，为了尽可能的不影响原有代码逻辑，我们考虑使用适配器模式，该计算接口还是以原来的逻辑返回，让新的方案适配原有的方案。只需要新增一个适配者接口和一个适配器即可，不需要改动原有的代码结构。

代码实现

目标角色（原有的代码逻辑）

public interface travelService {

    Map<String,Object> compute(TravelParam param);
    
}

适配者角色（新的计算方案）

public interface TravelAdaptee {

  /**
   * 计算金额
   * @param param
   * @return
   */
  Map<String,Object> compute(TravelParam param);

}

@Service("gat")
public class GatTravelService implements TravelAdaptee {

  @Override
  public Map<String,Object> compute(TravelParam param) {
    Map<String,Object> resMap = new HashMap<>();
    //具体代码实现
    return resMap;
  }
}

适配器角色

@Component
public class TravelAdapter {

  @Autowired
  private TravelService travelService;

  @Autowired
  private Map<String,TravelAdaptee> adapteeMap;

  public Map<String,Object> compute(TravelParam param){
    //系统默认计算方式
    if(TravelEnum.DEFAULT.getCode().equals(vo.getType())){
      return travelService.compute(param);
    }
    //新的计算方案
    return adapteeMap.get(vo.getType()).compute(param);
  }
}

controller层调用

@RestController
@RequestMapping("/travel")
public class TravelController {

    @Autowired
    private BaoGanAdapter baoGanAdapter;

    @PostMapping(path = "/compute")
    public Response compute(@RequestBody TravelParam param){
        return Response.success().setData(baoGanAdapter.computeBaoGanFee(param));
    }

}

如果之后又出现了新的方案，我们继续增加适配者接口的实现类即可，如果不需要某个方案，可以直接删除相应的实现类，其他代码完全不需要改动，实现了新增代码与原有代码之间的解耦，避免了对现有代码的污染。