适配器模式
适配器模式是什么,你一定不难理解,因为现实中到处都是。比如说:
如果你需要在欧洲国家使用美国制造的笔记本电脑,你可能需要使用一个交流电的适配器……
当你不想改变现有的代码,解决接口不适配问题,便可使用适配器模式,你可以写一个类,将新厂商接口转接成你所期望的接口。
定义适配器模式:将一个类的接口,转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间。
现在我们已经知道什么是适配器了,让我们后退一步,再次看看各部分之间的关系。
类图:
让我们以开头所提到的电脑电源插头适配的问题为例:
新建一个电脑类:
1 2 3 4 5 6 7 8 9 10 11 |
|
创建一个两孔插座接口:
1 2 3 |
|
再创建一个三孔插座类:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
创建一个适配器:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
测试类
1 2 3 4 5 6 7 8 |
|
运行结果:
其他
实际上适配器模式中有“两种”适配器:“对象”适配器和“类”适配器。
究竟什么是“类”适配器?为什么我们还没告诉你这种适配器?因为你需要多重继承才能够实现它,这在Java中是不可能的。但是当你在使用多重继承语言的时候,还是可能遇到这样的需求。
让我们看看多重继承的类图:
看起来很熟悉吗?没错,唯一的差别就在于适配器继承了Target和Adaptee。而对象适配器利用组合的方式将请求传送给被适配者。
对象适配器和类适配器使用两种不同的适配方法(分别是组合与继承)。
适配器模式适用场景
- 重复使用现有的类,而此类的接口不符合系统的需要。在遗留代码复用、类库迁移等方面非常有用。
- 想要建立一个可以重用的类,用于与一些彼此之间没有太大关联的一些类,包括一些可能在将来引进的类一起工作。
- 使用第三方组件或中间件,组件接口定义和自己定义的不同,不希望修改自己的接口,但是要使用第三方组件接口的 功能,避免重复造轮子。
适配器模式优缺点
优点:
- 将目标类和适配者类解耦。
- 增加了类的透明性和复用性,将具体的实现封装在适配者类中,对于客户端类来说是透明的,提高了适配者的复用性。
- 灵活性和扩展性都非常好,符合开闭原则
类适配器优点:
- 由于适配器类是适配者类的子类,因此可以在适配器类中置换一些适配者的方法,使得适配器的灵活性更强。
对象适配器优点:
- 把多个不同的适配者适配到同一个目标,也就是说,同一个适配器可以把适配者类和他的子类都适配到目标接口。
缺点:
- 实现适配器所需要的工作和目标接口的大小成正比,接口越复杂适配器也越复杂。
类适配器缺点:
- 对于Java、C#等不支持多重继承的语言,一次最多只能适配一个适配者类,而且目标抽象类只能为接口,不能为类,其使用有一定的局限性,不能将一个适配者类和他的子类同时适配到目标接口。
对象适配器的缺点:
- 与类适配器模式相比,要想置换适配者类的方法就不容易。
通过上一篇你已经知道适配器模式是如何将一个类的接口转换成另一个符合客户期望的接口的。你也知道在Java中要做到这一点,必须将一个不兼容接口的对象包装起来,变成兼容的对象。
我们现在要看一个改变接口的新模式,但是它改变接口的原因是为了简化接口,这个模式被巧妙的命名为外观模式。它将一个或数个类的复杂的一切都隐藏在背后,只显露出一个干净美好的外观。
定义
外观模式定义:外观模式提供了一个统一的接口,用来访问子系统中的一群接口。外观定义了一个高层接口,让子系统更容易使用。
外观模式实现了最少知识原则(Least Knowledge principle),这个原则希望不要让太多的类耦合在一起,对用户来说只和一个外观类打交道了,达到客户和一群子系统的解耦。
例题:搭建一个家庭影院系统
系统内包含设备:DVD播放器、投影机、自动屏幕、立体声音响、爆米花机........
来看看这些组件的组成:
当你把所有设备布置好后,准备看电源时...你忘了你必须要先一个个启用这些设备...关闭时也还将要进行一遍反向操作(崩溃....)。
结果你发现要使用你的家庭影院是那么的麻烦!
因此,我们引入外观模式,有了外观模式,通过实现一个更合理的接口的外观类,你可以将一个复杂的子系统变的容易使用。看看改变之后的类图:
定义这些媒体类:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 |
|
多媒体的具体类准备好就可以定义外观模式类了。
外观模式类:俩方法,一个看电影-打开一系列设备,一个电影结束-关闭一系列设备
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 |
|
测试
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
通过上面的代码可以看出,每个类对象都要执行一些方法,如果直接new这些类创建对象去调方法会与这些类产生耦合,这时单独再写一个外观类,构造初始化时拿到这些类对象,在一个方法里去调这些类对象的方法,这样对客户来说只和一个类打交道,与子系统的一堆类解耦了。此类原则即为:最少知识原则
最少知识原则:只和你的密友谈话。
客户端只和外观谈话,不和子设备,如DVD播放机、投影仪等谈话,降低了客户端和设备的耦合度。
下面给出最少知识原则的指导思想:
就任何对象而言,在该对象的方法内,我们只应该调用属于以下范围的方法:
1.该对象本身
2.被当做方法的参数而传过来的对象
3.该方法所创建或实例化的任何对象
4.对象的任何组件
尽可能自己封装子设备的方法,以便减少客户端和子设备的耦合。
外观模式优点
松耦合:使客户端与子系统之间解耦,让子系统内部的模块功能更容易扩展与维护。
简单易用:客户端无需了解子系统的内部实现及内部构成,只需要与外观类交互即可。
更好地划分访问层次:部分方法对外,部分方法对内交互使用。子系统将暴露在外的功能集中到外观类中可以隐藏子系统内部细节。
适配器、装饰者、外观模式对比
- 在介绍装饰者模式时,引出了一个开闭原则,即对修改关闭,对扩展开放。装饰者模式主要强调的是在不改变原有类的基础上,添加新功能。
- 适配器模式主要是对适配对象进行调整,以便适合消费者的需求。从而达到消费者和被适配者解耦的目的。
- 外观模式的特点主要是简化接口,以及减少客户端对外观组件的耦合。因为如果客户端变化来,组件的子系统变化了,不用影响客户端。除此之外,在封装组件时,适当的在外观类中添加一些自己想要的规则。如上面例子中各设备的开关顺序
总结
- 当需要使用一个现有的类,而其接口并不符合你的需要时,就使用适配器。
- 当需要简化并统一一个很大的接口或者一群复杂的接口时,使用外观。
- 适配器改变接口以符合客户的希望
- 外观将一个客户从复杂的子系统中解耦。
- 实现一个适配器可能需要一番功夫,也可能不费工夫,视目标接口的大小与复杂度而定。
- 实现一个外观,需要将子系统组合进外观中,然后将工作委托给子系统执行。
- 适配器模式有两种形式,对象适配器和类适配器。类适配器需要用到多重继承。
- 你可以为一个子系统实现一个以上的外观。
- 适配器将一个对象包装起来以改变其接口;装饰器将一个对象包装起来以增加新的行为和责任,而外观将一群对象包装起来以简化其接口。