从真实业务场景了解适配器模式

阅读本文大概需要 10 分钟

本文目录

1. 引言
2. 适用场景
3. 简单例子编码
4. 业务场景举例
5. 框架运用举例

引言

小明和小红从中国出发到英国玩，到了酒店的房间

小红 🥺：我手机怎么没电了，我要充电，不对啊，小明你看外国的插座和我们中国的咋不一样，我的充电器只有两个头，为什么这个插座是三个头

小明 😎：宝，咋们中国的手机充电器是阴极、阳极，外国多了一个地极，所以我们需要一个 “适配器” 就可以给我们手机充电啦

小红 🤭：那你带了吗？

小明 🤨：没有

小明卒，本文结束。

例子虽然不咋样，但是简单理解，说明了问题

通俗理解，适配器就是一个中间角色，起到一个协调兼容的作用

在我们软件开发上理解，适配器模式是结构型的设计模式，将一个类的接口转换成客户期望的另一个接口，使得原本接口不兼容的类可以在一起工作

它在我们开发软件中的优点就是能提高类的透明性和复用度，现有的类复用不需要改变，解决了目标类和现有类不匹配的问题。并且目标类和适配器类解耦，提高程序扩展性

缺点也显而易见，增加系统代码可读的难度，比如调用 a 接口，其实内部已经偷偷调用了 b 接口

适用场景

适配器适用的场景通常为已经存在的类，它的方法和需求不匹配

当然如果是强势的合作方，可以完全以自己的接口为主，但是通常情况是会随着软件维护，由于不同产品，不同厂家造成功能类似而接口不相同，在此种情况下，就需要用到适配器（在下文业务场景中，会具体举例）

简单举例

适配器模式通常分为对象适配和类适配，最大的区别就在于一个是使用类继承来实现，一个是使用组合来实现

我们先来举例 类适配

假设现存一个 音频播放的 MediaPlayer 接口

public interface MediaPlayer {
    void play();
}

旧的播放器 OldMediaPlayer 只支持播放 Mp4 格式的影片

public class OldMediaPlayer implements MediaPlayer {
    @Override
    public void play() {
        System.out.println("播放 Mp4 中");
    }

}

搞个测试类看一下