昨天上演了一场惊险时刻。我无意中在网上随便查查资料，结果发现《第二行代码》中用到的天气服务提供商竟然 改！接！口！了！当时我整个人直接懵逼了，这比《第一行代码》还惨，《第一行代码》至少是书发布了很长一段时间，天气接口才失效的，这《第二行代码》还没发布呢，接口就给改了。关键是《第二行代码》还已经送印了，我立即打电话给出版社，紧急叫停了印刷。
虽然印刷叫停了，但是留给我的时间并不多，如果我不能在两天之内改好所有出问题的部分，那么整个《第二行代码》的出版时间就要推迟。我思考了一下，为了能让改动最小化，我决定使用设计模式中的适配器模式来解决这个问题。
我自己快速编写了一个中间层服务器，然后由中间层服务器去访问天气服务的新接口，接收到返回的天气数据之后再做一次格式转换，最终仍然以之前接口的格式返回数据。这样，书中基本就不用修改任何内容，只需要将之前的天气信息请求地址改成我写的这个中间层服务的地址就行了。另外，使用这种方式之后，以后再也不用担心什么接口失效的问题了，不管第三方天气接口怎么变化，我只需要改一下中间层服务器的代码就可以了，书中的内容不会有任何改变。
整个修改过程我大概花了两个小时左右完成，最终没有影响到出版时间，总算是有惊无险。
另外，本篇文章正好讲的也是适配器模式，真是无巧不成书。希望我应用适配器模式的这个例子也算是为本篇文章开了个好头吧。
本篇是 张拭心 第三篇投稿，照例是讲设计模式，想必很多朋友对他的文风印象深刻。文末有作者的设计模式文章合集，感兴趣的朋友可以看一看。
张拭心 的博客地址：
http://blog.csdn.net/u011240877
不知道什么时候开始，总听到“ XXX 小伙娶乌克兰美女” 的新闻，比如 农村小伙娶乌克兰美女语言不通 翻译软件立功 等等，我仔细地看了几篇新闻，发现居然不是标题党，新闻里的乌克兰妹子长得真不错，上张图：
看完这些新闻和照片，我心里有三个疑问：
经过我大量的研究，得出了答案：
1. 乌克兰真的美女很多吗？
答：是的。
首先从世界地图可以看到，乌克兰地处东欧多个国家交界处，国内民族多达 110 个，各名族之间通婚比较多，久而久之导致混血美女比例比较高。
而且，乌克兰的气候环境也比较养人，一年到头冷多热少，阳光直射时间短，导致大多数女孩子皮肤白皙。
除此外，乌克兰姑娘特别注重外表，打扮的比较精致时尚。
2. 为什么乌克兰美女爱嫁给中国男人？
答：除主观因素外，有两点客观因素很重要。
近些年乌克兰并不富裕，距离大家心中的资本主义发达国家还有段距离。一方面生产停滞，经济增长无力；另一方面，乌克兰还要面临战乱带来的货币贬值、外资流出、物价上涨等压力，财政“只出不进”，整个国家“干耗”外汇储备。所以许多乌克兰姑娘选择外嫁。
此外，由于文化、社会福利等原因，许多乌克兰男人有酗酒、懒散的习惯，而中国男人在国际上给人一种体贴、勤劳、顾家的形象，所以相较之下，中国男人是比较好的选择。
给老婆削苹果
给老婆当座椅
3.翻译软件可以化腐朽为神奇，软件开发过程中是否可以参考呢？
翻译软件把小伙的汉语转换成了乌克兰语，在软件开发过程中这就是一种“复用”！那有什么设计模式可以达到这种效果呢？
我们先来模拟实现下这个翻译过程：
a.首先定义一个小目标，就是可以跟妹子说乌克兰语，萨瓦迪卡爱米思油~
b. 然而理想很丰满，现实很骨感，小伙只会川普：
c. 这时候翻译器上场了，化腐朽为神器，帮助小伙具有能说乌克兰语的功能：
d. 可以看到，翻译器持有一个只会中文小伙的引用，实现了说乌克兰语的接口，在需要说乌克兰语的时候，经过语法翻译最终调用小伙的说中文：
@Test
public void testAdapterPattern(){
Chinese me = new Chinese();
Ukrainian ukrainianMan = new Translator(me);
ukrainianMan.sayUkrainian("我爱你");
}
e. 翻译 + 川普小伙 = 乌克兰语达人，运行结果：
f. 画一下上面这个过程的 UML 图：
目标类，即能说乌克兰语，是一个接口；
实际情况，即只能说汉语，是一个既成的、无法改变的类；
中间人，即翻译软件，实现目标接口（乌克兰语），引用了实际情况（中国小伙），经过偷梁换柱，让中国小伙具有了新的功能
Client 客户端，乌克兰妹子，希望能和会乌克兰语的人沟通，由于翻译软件实现了乌克兰语接口，因此可以直接实例化一个翻译软件作为乌克兰语人。
这就是适配器模式，又称包装模式
将一个类的接口转换为客户希望的另一个接口。
适配器模式可以使原本不兼容的接口变得兼容，即能复用。
一个很形象的例子
适配器模式主要分为两种：类适配器和对象适配器
1. 对象适配器，与被适配类是关联关系
上面举的例子就是适配器 。Adapter 中持有一个被适配类对象的引用，因此叫做对象适配器。
对象适配器的 UML 图和上述例子一致，所以就偷个懒不列出来了。
2. 类适配器，与被适配类是继承关系
Adapter 通过继承被适配类，从而可以调用被适配类的方法。
举个栗子，类适配器下的翻译中介:
采用类适配器模式的翻译软件，继承了被适配类 Chinese，实现了目标接口 Ukrainian，从而使得原本不能使用的 sayChinese(string) 方法可以被调用。
调用时：
@Test
public void testClassAdapterPattern(){
Ukrainian ukrainianMan = new ClassTranslator();
ukrainianMan.sayUkrainian("刘奶奶找牛奶奶买榴莲牛奶");
}
对比一下对象适配器的代码：
可以看到，对象适配器支持传入一个被适配器对象，因此可以做到对多种被适配接口进行适配，而类适配器直接继承，无法动态修改，所以一般情况下对象适配器使用更广泛。
使用场景：就是想复用，不想多创建！
《大话设计模式》里看到的一段话很好
事先设计统一接口
问题初现及时重构（下策）
无法改变只能适配（下下策）
说起适配器 Adapter，最熟悉的就是 ListView 和 RecyclerVIew 的适配器了，本来准备下一篇就写 ListVIew 源码中的适配器模式，但考虑到 ListView 中还有观察者模式，所以下一步先总结观察者模式，然后再统一进行 ListView 源码解析。
1. 适配器模式调用时强调“最终要转换成的目的接口”，以本文例子，Translator 最终的目的是变成一个 Ukrainian ：
Ukrainian ukrainianMan = new Translator(me);
然后客户端调用的是 Ukrainian 的方法
2. 而代理模式是通过代理，拦截调用，最终以代理类完成工作，以我这篇文章
http://blog.csdn.net/u011240877/article/details/52264283
为例 ：
Agent songJJ = new Agent(baoqiang, false);
总结：
适配器模式以达到适配最终接口为目的
代理模式以拦截、处理为目的
备注：
作者的 csdn 设计模式总结文章
http://blog.csdn.net/column/details/zsxdesignpattern.html
每天学习累了，看些搞笑的段子放松一下吧。关注最具娱乐精神的公众号，每天都有好心情。
如果你有好的技术文章想和大家分享，欢迎向我的公众号投稿，投稿具体细节请在公众号主页点击“投稿”菜单查看。
欢迎长按下图 -> 识别图中二维码或者扫一扫关注我的公众号：
