巧妙的运用适配器模式,让你的工作量至少减轻一半

简介: 今天我们就一起来聊聊使用超广的适配器模式!

一、介绍

适配器模式,顾名思义,就是将一个类的接口转换成客户希望的另一个接口,使接口不兼容的类可以一起工作,也被称为包装器模式(Wrapper)。

在适配器模式中,通常通过增加一个新的适配器类来解决接口不兼容的问题,使得原本没有任何关系的类可以协同工作。

从设计的角度看,适配器模式涉及到三个角色:

  • 适配器类:适配器类可以调用另一个接口,从而实现接口的转换;
  • 被适配类:被适配类定义了一个已经存在的接口,这个接口需要适配;
  • 客户角色:客户类提出使用具体类的请求;

二、示例

在 java 中,适配器模式有两种,类适配器和对象适配器,下面我们一起来看看!

2.1、类适配模式

首先,我们创建一个接口Phone,接口的实现类为HuaweiPhone

public interface Phone {
    void productPhone();
}
public class HuaweiPhone implements Phone {
    @Override
    public void productPhone() {
        System.out.println("生产一部华为手机");
    }
}

在创建另一个接口Player,如果Player的实现类想调用HuaweiPhone中的productPhone方法,该怎么办呢?

最简单的方法,就是将productPhone的方式逻辑抄一遍,但是这种方法显然不高效!

可以通过创建一个适配器ExpensiveAdapter,使之继承HuaweiPhone,来解决接口转换的问题,如下:

public class ExpensiveAdapter extends HuaweiPhone implements Player {
    @Override
    public void action() {
  //调用HuaweiPhone中的productPhone方法
        productPhone();
        System.out.println("用手机播放音乐");
    }
}

测试类如下:

public class AdapterClient {
    public static void main(String[] args) {
        ExpensiveAdapter adapter = new ExpensiveAdapter();
        adapter.action();
    }
}

即可实现接口的转换!

但是这种方法,也有很大的局限性,假如Phone接口的实现类有多个呢?

我们知道,类是无法多继承的,对象适配模式就派上用场了!

2.2、对象适配模式

同样的,我们可以对ExpensiveAdapter类进行一定的优化,如下:

public class ExpensiveAdapter implements Player {
    private Phone phone;
    public ExpensiveAdapter(Phone phone) {
        this.phone = phone;
    }
    @Override
    public void action() {
        //调用Phone接口中的productPhone方法
        phone.productPhone();
        System.out.println("用手机播放音乐");
    }
}

测试客户端如下:

public class PlayerClient {
    public static void main(String[] args) {
  //对象适配
        ExpensiveAdapter adapter = new ExpensiveAdapter(new HuaweiPhone());
        adapter.action();
    }
}

相比类适配模式,有木有发现对象适配模式更加灵活~

三、应用

在 jdk 中,适配器设计模式应用也非常广泛,例如我们熟悉的io包,其中字节流转字符流,就使用到了适配器模式!

15.jpg

16.jpg

其中,最广泛的莫过于Spring中的ioc对象依赖关系,在类A中,通过引入另一个类B 对象,就可以调用类 B 中的方法了,从而实现方法的协同工作!

四、总结

适配器模式,可以让任何两个没有关联的类一起运行,提高了类的复用;例如,现在非常流行的Mybatis-plus持久框架,里面的Service层就是典型的类适配模式,在Service层可以很方便的进行crud调用,开发人员基本不需编写crud的代码,开发效率大大提升!

但是,设计时如果过多的使用适配器,会让系统非常零乱,不易整体进行把握。比如,明明看到调用的是另一个接口,反而另一个接口又回调了自身,一个系统如果太多出现这种情况,无异于一场灾难。

因此在设计使用的时候,尽可能层次分明,接口名包括方法名,取名的时候应该规范化定义!

相关文章
|
2月前
|
存储 缓存 持续交付
后端世界的微妙平衡:性能与可维护性的博弈###
【10月更文挑战第15天】 在软件开发的浩瀚宇宙里,后端开发犹如一颗星辰,既需璀璨夺目以支撑业务辉煌,又得稳若磐石确保系统长青。本文探讨了后端开发中性能优化与代码可维护性之间的微妙平衡,通过实例分析与策略建议,揭示了如何在追求极致速度的同时,保持代码的清晰、可读与易于迭代,实现技术与艺术的和谐共生。我们相信,正如印度圣雄甘地所言:“你必须成为你希望在世界上看到的改变。”开发者在面对复杂系统挑战时,也应主动寻求变革,探索更高效的解决方案。 ###
41 3
|
5月前
软件复用问题之减少软件系统中的“熵增”,如何解决
软件复用问题之减少软件系统中的“熵增”,如何解决
|
5月前
软件复用问题之衡量是否应该复制或复用代码,如何解决
软件复用问题之衡量是否应该复制或复用代码,如何解决
|
5月前
|
缓存 自然语言处理 Java
浅析JAVA日志中的性能实践与原理解释问题之减少看得见的业务开销问题如何解决
浅析JAVA日志中的性能实践与原理解释问题之减少看得见的业务开销问题如何解决
|
缓存 算法 Cloud Native
面试技巧:如何在有限时间内优化代码性能
面试技巧:如何在有限时间内优化代码性能
75 0
|
SQL 缓存 NoSQL
写代码有这16个好习惯,可以减少80%非业务的bug
每一个好习惯都是一笔财富,本文整理了写代码的16个好习惯,每个都很经典,养成这些习惯,可以规避多数非业务的bug!希望对大家有帮助哈,谢谢阅读,加油哦~1. 修改完代码,记得自测一下...
353 0
|
安全 Windows
这5款软件虽然知名度不高,但不代表不好用
其实有许多工具,知名度不高,用的人也很少,不过并不代表它们不好用,小编励志做一个合格的搬运工,让大家都能用上好用的软件。
117 1
|
测试技术 应用服务中间件
软件测试面试题:在给定的测试环境下进行,考虑被测系统的业务压力量和典型场景?
软件测试面试题:在给定的测试环境下进行,考虑被测系统的业务压力量和典型场景?
175 0
|
机器学习/深度学习 新零售 算法
主动学习入门篇:如何能够显著地减少标注代价
在大数据和算力的助力下,深度学习掀起了一波浪潮,在许多领域取得了显著的成绩。以监督学习为主的深度学习方法,往往期望能够拥有大量的标注样本进行训练,模型能够学到更多有价值的知识(如下左图展示了3组常见的图像分类数据集,拥有上万的标注样本)。
7805 0
主动学习入门篇:如何能够显著地减少标注代价
|
数据库 运维
小小的IP,大大的耦合,你痛过吗?
使用内网域名来替换内网IP,只是一个很小的优化点,但对于IP解耦却是非常的有效。
591 0