【笨鸟先飞】Java重新学习日记20--设计模式之适配器模式

设计模式是面向对象设计的精华，而面向对象终归于继承、封装和多态。我本次学习设计模式重在体会面向对象设计的思维方式，同时知晓该设计模式的应用场景，当后来遇到相似场景，可以直接借鉴该设计模式。

 

之前学习了命令模式，觉得命令模式里面的Involker实在是太厉害了，巧妙的将输入放和接收方分开，而且不同的接收方，使用Involker之后接收方将变成相似起来。实际上Involker本身就是一种设计模式的衍生物，这种设计模式叫做适配器模式。

 

适配器模式，将一个方法由另外一个方法封装起来，将一个对象由另一个对象封装起来，将一个类由另一个类封装起来。

 

使用的时候，是将一个目标A，放入B中，然后B提供很多方法，这些方法会去调用A的一些方法，客户端会使用B来处理，最终使用的是A的东西。

 

根据我两年半的工作经验，适配器的使用场景基本上是针对于A本身不可修改，而我们对A的使用比较复杂。

 

如命令模式的receive就是A就是不可变的对象，用command + Involker（B）将其包起来，这就体现了适配器的设计模式思路，用B将A包装起来给C用。场景上看，并没有体现使用情况特别复杂，所以不是适配器的典型场景。

 

在之前学习的抽象工厂模式中，我们用一个方法来包括多个对象的创建，这样在增加新的需要创建对象的时候，就只需要修改这个方法就行，不用修改被创建对象。这也体现了适配器设计模式的思路，属于调用特别复杂，所以封装一下。

 

实际情况是，我们需要使用A的大部分信息，同时，对这些信息需要进行一些加工后来使用，这种情况下，用一个B来统一加工A，而客户端直接使用B加工后的信息，就是适配器模式。

 

完整的适配器模式使用的不多，但是适配器模式的思路却流传很广。

 

真正使用适配器的地方，几乎都是跨系统的数据交流。其他应用给的数据，我们确实没法修改，才使用适配器。本地的数据完全可以将数据写成适合规格的形式。

 

所以，不要滥用适配器模式，因为，如果A本身就能够被C很好的使用，就不用在增加一个B了。

 

适配器的基本模式就讲清楚了，简单复习一下。

 

标准说法，之前的例子中：

A叫做源

B叫做适配器

C叫做目标

 

A的特征是不可修改。

C的特征是需要特定的数据，这个数据是通过A的数据间接得到。

B是我们自己写的适配器，用于计算A的数据提供给C。即B提供有用的数据。

 

我们具备不只一个C需要用到B的有用数据。也就是有多个地方需要用到B的有用数据，所以我们才需要用一个B来专门计算。

 

到此，这种适配器模式我们叫做类适配器模式，就是有个B来处理A的数据，提供给多个C使用，避免在不同的C中都专门去处理一遍A的数据。

 

如果场景更加复杂，有多个A1，A2，A3等等不可变的对象，他们被多个C所使用。

 

这种情况，我们直观的解决方案是为A1，A2，A3各配一个适配器即B1，B2，B3。这是一种方案。

 

同样还有一种方案，用一个B，把A1，A2，A3都放到里面，然后在目标获取的时候，根据自己的需要，在B中进行筛选后获取。

 

后面这种方案叫做，对象适配器模式。

 

对象适配器模式，还是适配器模式，不过采用组合的方式，将多个不同的源A1 A2 A3放到一个B中。这样在B的使用上会麻烦些，但是一个B 就能把A1

 

 

综上所述，适配器的目的是将A的数据的处理方法由B来统一完成，避免相同的处理方法，在C1，C2，C3中反复出现。后期A的数据由变得，我们也只需要修改B的处理方法，这样完美的达成的解耦。

 

就适配器模式来带的解耦方法，其核心是对某种数据的处理，由一个类来统一完成。

 

衍生开来，当某一个接口里面有很多种方法需要实现，每个实现该接口的类都需要去实现里面的所有方法，但实际上，就这个接口而言，可能里面的有些方法，所有实现该接口的都采用相同的方法。

 

这种时候，我们可以对方法进行适配。使用一个抽象类，对这个接口的采用相同手法实现的方法，进行统一实现。

 

这样很多类就可以通过继承这个抽象类，来直接完成对该接口的普通方法的定义，而避免反复定义一个方法。

 

这个看上去和适配器模式差别很大，但是其运用了适配器模式的原理。我们称之为缺省适配模式。

 

以上就是学习的三种适配器模式：类适配、对象适配和缺省适配。这三者使用的场景要素是，源内容不可变，目的调用源的场景相对复杂，希望有适配器进行统一简化。