在阎宏博士的《JAVA与模式》一书中开头是这样描述适配器(Adapter)模式的:程序员
适配器模式把一个类的接口变换成客户端所期待的另外一种接口,从而使本来因接口不匹配而没法在一块儿工做的两个类可以在一块儿工做。编程
用电器作例子,笔记本电脑的插头通常都是三相的,即除了阳极、阴极外,还有一个地极。而有些地方的电源插座却只有两极,没有地极。电源插座与笔记本电脑的电源插头不匹配使得笔记本电脑没法使用。这时候一个三相到两相的转换器(适配器)就能解决此问题,而这正像是本模式所作的事情。app
适配器模式有类的适配器模式和对象的适配器模式两种不一样的形式。编辑器
类的适配器模式把适配的类的API转换成为目标类的API。ide
在上图中能够看出,Adaptee类并无sampleOperation2()方法,而客户端则期待这个方法。为使客户端可以使用Adaptee类,提供一个中间环节,即类Adapter,把Adaptee的API与Target类的API衔接起来。Adapter与Adaptee是继承关系,这决定了这个适配器模式是类的:this
模式所涉及的角色有:spa
● 目标(Target)角色:这就是所期待获得的接口。注意:因为这里讨论的是类适配器模式,所以目标不能够是类。设计
● 源(Adapee)角色:如今须要适配的接口。对象
● 适配器(Adaper)角色:适配器类是本模式的核心。适配器把源接口转换成目标接口。显然,这一角色不能够是接口,而必须是具体类。继承
public interface Target { /** * 这是源类Adaptee也有的方法 */ public void sampleOperation1(); /** * 这是源类Adapteee没有的方法 */ public void sampleOperation2(); }
上面给出的是目标角色的源代码,这个角色是以一个JAVA接口的形式实现的。能够看出,这个接口声明了两个方法:sampleOperation1()和sampleOperation2()。而源角色Adaptee是一个具体类,它有一个sampleOperation1()方法,可是没有sampleOperation2()方法。
public class Adaptee { public void sampleOperation1(){} }
适配器角色Adapter扩展了Adaptee,同时又实现了目标(Target)接口。因为Adaptee没有提供sampleOperation2()方法,而目标接口又要求这个方法,所以适配器角色Adapter实现了这个方法。
public class Adapter extends Adaptee implements Target { /** * 因为源类Adaptee没有方法sampleOperation2() * 所以适配器补充上这个方法 */ @Override public void sampleOperation2() { //写相关的代码 } }
与类的适配器模式同样,对象的适配器模式把被适配的类的API转换成为目标类的API,与类的适配器模式不一样的是,对象的适配器模式不是使用继承关系链接到Adaptee类,而是使用委派关系链接到Adaptee类。
从上图能够看出,Adaptee类并无sampleOperation2()方法,而客户端则期待这个方法。为使客户端可以使用Adaptee类,须要提供一个包装(Wrapper)类Adapter。这个包装类包装了一个Adaptee的实例,从而此包装类可以把Adaptee的API与Target类的API衔接起来。Adapter与Adaptee是委派关系,这决定了适配器模式是对象的。
public interface Target { /** * 这是源类Adaptee也有的方法 */ public void sampleOperation1(); /** * 这是源类Adapteee没有的方法 */ public void sampleOperation2(); }
public class Adaptee { public void sampleOperation1(){} }
public class Adapter { private Adaptee adaptee; public Adapter(Adaptee adaptee){ this.adaptee = adaptee; } /** * 源类Adaptee有方法sampleOperation1 * 所以适配器类直接委派便可 */ public void sampleOperation1(){ this.adaptee.sampleOperation1(); } /** * 源类Adaptee没有方法sampleOperation2 * 所以由适配器类须要补充此方法 */ public void sampleOperation2(){ //写相关的代码 } }
● 类适配器使用对象继承的方式,是静态的定义方式;而对象适配器使用对象组合的方式,是动态组合的方式。
● 对于类适配器,因为适配器直接继承了Adaptee,使得适配器不能和Adaptee的子类一块儿工做,由于继承是静态的关系,当适配器继承了Adaptee后,就不可能再去处理 Adaptee的子类了。
对于对象适配器,一个适配器能够把多种不一样的源适配到同一个目标。换言之,同一个适配器能够把源类和它的子类都适配到目标接口。由于对象适配器采用的是对象组合的关系,只要对象类型正确,是否是子类都无所谓。
● 对于类适配器,适配器能够重定义Adaptee的部分行为,至关于子类覆盖父类的部分实现方法。
对于对象适配器,要重定义Adaptee的行为比较困难,这种状况下,须要定义Adaptee的子类来实现重定义,而后让适配器组合子类。虽然重定义Adaptee的行为比较困难,可是想要增长一些新的行为则方便的很,并且新增长的行为可同时适用于全部的源。
● 对于类适配器,仅仅引入了一个对象,并不须要额外的引用来间接获得Adaptee。
对于对象适配器,须要额外的引用来间接获得Adaptee。
建议尽可能使用对象适配器的实现方式,多用合成/聚合、少用继承。固然,具体问题具体分析,根据须要来选用实现方式,最适合的才是最好的。
系统须要使用现有的类,而此类的接口不符合系统的须要。那么经过适配器模式就可让这些功能获得更好的复用。
在实现适配器功能的时候,能够调用本身开发的功能,从而天然地扩展系统的功能。
过多的使用适配器,会让系统很是零乱,不易总体进行把握。好比,明明看到调用的是A接口,其实内部被适配成了B接口的实现,一个系统若是太多出现这种状况,无异于一场灾难。所以若是不是颇有必要,能够不使用适配器,而是直接对系统进行重构。
缺省适配(Default Adapter)模式为一个接口提供缺省实现,这样子类型能够从这个缺省实现进行扩展,而没必要从原有接口进行扩展。做为适配器模式的一个特例,缺省是适配模式在JAVA语言中有着特殊的应用。
和尚要作什么呢?吃斋、念经、打坐、撞钟、习武等。若是设计一个和尚接口,给出全部的和尚都须要实现的方法,那么这个接口应当以下:
public interface 和尚 { public void 吃斋(); public void 念经(); public void 打坐(); public void 撞钟(); public void 习武(); public String getName(); }
显然,全部的和尚类都应当实现接口所定义的所有方法,否则就根本通不过JAVA语言编辑器。像下面的鲁智深类就不行。
public class 鲁智深 implements 和尚{ public void 习武(){ 拳打镇关西; 大闹五台山; 大闹桃花村; 火烧瓦官寺; 倒拔垂杨柳; } public String getName(){ return "鲁智深"; } }
因为鲁智深只实现了getName()和习武()方法,而没有实现任何其余的方法。所以,它根本就通不过Java语言编译器。鲁智深类只有实现和尚接口的全部的方法才能够经过Java语言编译器,可是这样一来鲁智深就再也不是鲁智深了。以史为鉴,能够知天下。研究一下几百年前鲁智深是怎么剃度成和尚的,会对Java编程有很大的启发。不错,当初鲁达剃度,众僧说:“此人形容丑恶、相貌凶顽,不可剃度他",可是长老却说:”此人上应天星、心地刚直。虽然时下凶顽,命中驳杂,久后却得清净。证果非凡,汝等皆不及他。”
原来如此!看来只要这里也应上一个天星的话,问题就解决了!使用面向对象的语言来讲,“应”者,实现也;“天星”者,抽象类也。
public abstract class 天星 implements 和尚 { public void 吃斋(){} public void 念经(){} public void 打坐(){} public void 撞钟(){} public void 习武(){} public String getName(){ return null; } }
鲁智深类继承抽象类“天星”
public class 鲁智深 extends 天星{ public void 习武(){ 拳打镇关西; 大闹五台山; 大闹桃花村; 火烧瓦官寺; 倒拔垂杨柳; } public String getName(){ return "鲁智深"; } }
这个抽象的天星类即是一个适配器类,鲁智深实际上借助于适配器模式达到了剃度的目的。此适配器类实现了和尚接口所要求的全部方法。可是与一般的适配器模式不一样的是,此适配器类给出的全部的方法的实现都是“平庸”的。这种“平庸化”的适配器模式称做缺省适配模式。
在不少状况下,必须让一个具体类实现某一个接口,可是这个类又用不到接口所规定的全部的方法。一般的处理方法是,这个具体类要实现全部的方法,那些有用的方法要有实现,那些没有用的方法也要有空的、平庸的实现。
这些空的方法是一种浪费,有时也是一种混乱。除非看过这些空方法的代码,程序员可能会觉得这些方法不是空的。即使他知道其中有一些方法是空的,也不必定知道哪些方法是空的,哪些方法不是空的,除非看过这些方法的源代码或是文档。
缺省适配模式能够很好的处理这一状况。能够设计一个抽象的适配器类实现接口,此抽象类要给接口所要求的每一种方法都提供一个空的方法。就像帮助了鲁智深的“上应天星”同样,此抽象类可使它的具体子类免于被迫实现空的方法。
缺省适配模式是一种“平庸”化的适配器模式。
public interface AbstractService { public void serviceOperation1(); public int serviceOperation2(); public String serviceOperation3(); }
public class ServiceAdapter implements AbstractService{ @Override public void serviceOperation1() { } @Override public int serviceOperation2() { return 0; } @Override public String serviceOperation3() { return null; } }
能够看到,接口AbstractService要求定义三个方法,分别是serviceOperation1()、serviceOperation2()、serviceOperation3();而抽象适配器类ServiceAdapter则为这三种方法都提供了平庸的实现。所以,任何继承自抽象类ServiceAdapter的具体类均可以选择它所须要的方法实现,而没必要理会其余的不须要的方法。
适配器模式的用意是要改变源的接口,以便于目标接口相容。缺省适配的用意稍有不一样,它是为了方便创建一个不平庸的适配器类而提供的一种平庸实现。
在任什么时候候,若是不许备实现一个接口的全部方法时,就可使用“缺省适配模式”制造一个抽象类,给出全部方法的平庸的具体实现。这样,从这个抽象类再继承下去的子类就没必要实现全部的方法了。