我们来看一下适配器模式,我们先来看一下定义和类型,定义是将一个类的接口转换成客户期望的另一个接口,
这里说的类的接口是被适配者,而另一个接口就是目标,目标类,使原本不兼容的类可以一起工作,类型是结构型,
例如我们笔记本的电源适配器,或者手机的电源适配器,都是一个意思
适配器的应用场景,已经存在的类,他的方法和需求不匹配时,方法结果相同或者相似,这个基础上如果出现这个场景,
适配器为了复用现有的类,好多数据或行为,都正确,但是呢,接口不符合,这个时候就可以采取适配器模式,是原有对象和
新接口匹配,那我们再看一下第二条,适配器模式不是软件设计阶段考虑的设计模式,是随着软件维护,由于不同产品,
不同厂家,造成功能类似,而接口不相同情况下的解决方案,这个比较重要,也就是说如果我们去做一个新的项目,新的系统,
那么在设计的时候,不要考虑适配器,适配器模式有点亡羊补牢的感觉,那设计阶段尽量避免使用,但是随着我们项目的不断地
发展,那这个时候就需要考虑适配器模式了
那我们看一下适配器模式的优点,能提高类的透明性,和复用,现有的类复用但不需要改变,解决现有类和目标类
不匹配的问题,那第二条呢,目标类和适配器类解耦,提高程序的扩展性,那我们可以使用适配器模式,开发自己的功能,
另外符合开闭原则,那具体的实现,都在适配器中,客户端知道的只有适配器类,扩展的话只需要扩展适配器类就可以,
而原有的类是不需要变化的,当然这里说的原则是指在某一个业务场景
那我们再看一下适配器的缺点,那适配器编写过程需要全面考虑,可能会增加系统的复杂性,另外会增加系统代码可读的难度,
如果过多的使用适配器,让我们的系统非常的凌乱,不易整理,比如我们调用的是第一个接口,其实内部已经适配成了调用第二个接口的实现,
那这种情况我们在读代码的时候,就很容易蒙圈,增加系统可读的难度
那我们再看一下适配器的扩展,这里主要分对象适配器模式和类适配器模式,那对象适配器符合组合复用原则,并且
使用委托机制,类适配器是使用类继承来实现的
再看一下适配器相关的设计模式,那适配器模式和装饰模式的对比,我们在装饰模式里面,已经讲了,
我们讲一下适配器模式和外观模式,适配器和外观都是对现有的类,系统的封装,那外观呢,定义了新的接口,
而适配器是复用原有的接口,适配器是使原有的接口,协同工作,而外观呢,则是在现在的接口中提供一个更方便的
访问入口,那我们如果强行的把外观模式也称之为适配的话,那这两个最大的区别就在于适配的力度不同,那外观模式呢
是用来适配整个子系统,就是说相关的子系统,例如我们之前讲的打开CPU,打开内存条,打开主板,打开硬盘等,所以外观
所针对的对象,力度更大
接下来我们会一起coding,会看一下UML,关于类适配器和对象适配器,再引入一个业务场景,然后看一下
UML的演变过程,源码分析会引着一起看一下JDK及Spring,SpringMVC,关于适配器模式的应用