设计模式之适配器模式

适配器模式.png

这是我参与8月更文挑战的第6天,活动详情查看:8月更文挑战java

欢迎来到今天的学习,今天咱们一块儿来学习下使用频率不是很高的可是极易搞懂的一种模式----适配器模式。多唠叨几句,我本月将会对java的设计模式精讲,欢迎点击头像,关注个人专栏,我会持续更新,加油!程序员

系列文章:设计模式

设计模式之单例模式markdown

设计模式之工厂模式网络

设计模式之建造者模式app

设计模式之代理模式ide

设计模式之访问者模式post

...持续更新中学习

话很少说,进入正题this

适配器模式

顾名思义,该模式确定是为了为兼容而生的。适配两个原本不兼容的事物,能够将二者友好相处,协同工做。

该模式的原始定义为:将类的接口转换为客户指望的另外一个接口,适配器可让不兼容的两个类一块儿协同工做。

注意:该定义中明确说明了适配器模式的关键点就在于转换而转换时要在已有的接口基础上作好兼容。

咱们也能够拿生活当中的例子更加形象的解释。好比咱们开会时用的投影仪,本电脑开放出来的接口,和大屏上的接口不兼容,这时候须要一个中间的适配器来转换下。

咱们程序员通常都须要分屏,一个写代码,一个看文档,一个查资料,将三个屏幕链接在一块儿不必定全部的接口就适用。像本人的mac电脑就不兼容,mac电脑上只开放了mac的扁形接口。还得本身买个适配器(该适配器开放了vga,HDMI,网络线插口),那么这个适配器,起到了无可替代的做用(下图便是适配器,也叫扩展器)

image.png

根据类图拆分讲解

适配器模式的通用类图以下:

image.png

从改图能够看到三个关键角色(也就是图中黄色部分)

  • 目标类, 用户期待的链接口,适配器类即将要进行适配的抽象类或接口;

  • 适配器类, 能够是类或接口,是做为具体适配者类的中间类来使用;

  • 具体适配者类, 能够是内部的类或服务,也能够是外部对象或服务。

其实不难发现,适配器模式封装了三个重要事实

  • 具体适配者类能够有不一样的接口

  • 用户在使用适配器类时实际上使用了多个接口;

  • 适配器类和具体适配者类引入了变化。

以下简图所示,适配器模式的类其实是做为中间者来封装变化的。

image.png

下面咱们根据实际代码来深刻理解下

代码展现

场景:拿咱们程序员用mac链接一个分屏的场景,根据咱们上面所说的类图和讲解来写下代码(必定要看注释)

//建立Target接口
public interface Target {
    //这是源类Adapteee没有的方法
    public void Request(); 
}


//建立源类(Adaptee)
public class Adaptee {
    
    public void SpecificRequest(){
    }
}


//建立适配器类(Adapter)
//适配器Adapter继承自Adaptee,同时又实现了目标(Target)接口。
public class Adapter extends Adaptee implements Target {

    //目标接口要求调用Request()这个方法名,但源类Adaptee没有方法Request()
    //所以适配器补充上这个方法名
    //但实际上Request()只是调用源类Adaptee的SpecificRequest()方法的内容
    @Override
    public void Request() {
    
        //重要:
        //适配器只是将SpecificRequest()方法做了一层封装,封装成Target能够调用的Request()而已
        //这里就是兼容,就是转换,把咱们苹果电脑的接口利用适配器(扩展器)链接到了分屏上
        this.SpecificRequest();
    }
}
复制代码

接下来,定义具体使用目标类,并经过Adapter类调用所须要的方法从而实现目标

public class AdapterPattern {

    public static void main(String[] args){
        Target mAdapter = new Adapter();
        //看似调用request. 实际上是SpecificRequest,
        mAdapter.Request();
    }
}
复制代码

这就是适配器模式。将一个类的接口变换成客户端所期待的另外一个接口,从而是本来由于接口不匹配而没法在一块儿工做的两个类可以在一块儿工做。

总结

我的认为当你碰到如下几种状况的时候可使用该模式:

  • 原有接口没法修改时

  • 适配不一样数据格式时

  • 须要过渡升级旧接口时(好比app升级须要一个审核期,可是后台代码一会儿就更新了)

适配器模式优势我认为仍是不少的,而后获得也就意味要牺牲一些。全部的模式都同样

优势:

  • 解耦:将目标类和适配者类解耦,经过引入一个适配器类重用现有的适配者类,而无需修改原有代码

  • 扩展性强: 在实现适配器功能的时候,能够调用本身开发的功能,任意扩展

  • 符合开放-关闭原则:同一个适配器能够把适配者类和它的子类都适配到目标接口;能够为不一样的目标接口实现不一样的适配器,而不须要修改待适配类

缺点嘛:我认为有如下几点:

一、若是适配器使用太多,会致使臃肿,总体系统会很是凌乱。

二、修改目标接口会致使全部适配接口都须要定制修改

三、一次只能适配一个抽象类或接口(由于java是单继承,多实现);

弦外之音

OK 今天的适配器就讲到这里,感谢你的阅读,若是你感受学到了东西,麻烦您点赞,关注。

我已经将本章收录在专题里,点击下方专题,关注专栏,我会天天发表干货,本月我会持续输入设计模式。

加油! 咱们下期再见

相关文章
相关标签/搜索