适配器模式

又接到一个小需求，就是将一个支持固定命令执行器修改为一个还能支持自定义命令的执行器同样的代码使用在不同的环境下执行基本一致的逻辑。

So easy！一顿噼里啪啦之后，到了关键，用什么来存储可用自定义命名的标记呢？之前由于历史原因固定命名的标记采用的是HashMap存储的，现在自定义没那么复杂用一个List足以。可以同样的代码逻辑需要操作两种不同的数据，那么问题来了，这是什么技术？这是适配。问题又来了，适配技术哪家强？当然是适配器模式咯。

先看我的代码：

之前的：

这里列这么多fun只是为了说明本类中很多方法都调用到了这个类成员变量（勘误：最后一个变量名还写错了）。现在要根据不同的环境使用另一个变量（是一个List），亲啊，这改起来太麻烦了吧。为了保持下面很多调用这个对象的方法不便，可以这样来操作。

看看下面的代码：

好吧，就是这样，为了保证后面的方法不改，新增了一个类（又要勘误了：这个类实现了Map的接口，当然有扩展也有一些没在这列出来），里面封装了两个对象，一个是用于固定命令的mCanSelectCommand还有用于支持自定义的mCanCustomDefineCommand。不同的两个数据对象，保持外部调用的统一接口，这就是个适配器。当然这段代码还需要优化，比如新增设置适配对象的接口，减少内部操作的判断等等。

抽象一下就可以得到对象适配器模式的一般表现形式。

外部调用它们的方法抽象为客户端也就是使用者；CanDefinedGesture是适配器；对应的List和Map就是适配者类就是中间需要包装的东西。这也是适配器模式的基本的角色。

按照常规的描述，其实这里面还有一个重要的角色，就是目标接口，因为归根到底，适配器就是为了接口的统一而不用修改数目众多的客户端，统一成什么样子呢，这个就是目标接口。显然我的例子也是有的，目标接口就是Map，没办法谁让代码中使用Map在先呢。

上面就是适配器模式的类图。这个模式还是简单明了哈。

这个模式在讲究快速迭代的移动互联网时代，扩展平行功能经常会使用到的，避免了调用者的修改，修改的目标是一组接口，也是面向接口编程的实践。

可能我是从实际重构代码出发的，例子不是很适合大家理解适配器模式的框架，同时也不知道有没有说明白，推荐一个博客可以看看 http://www.2cto.com/kf/201401/275535.html