Adapter
适配器模式
Intent
把一个类的接口转换成Client期望的另一个接口。适配器让类与类之间不至于因为接口不兼容而不能协同工作。
Wrapper
有时一个设计的时候就考虑重用(糊涂熊批注：这里的重用指的是功能的重用。)的工具箱(toolkit)类，仅仅因为接口跟应用程式需要的问题域特定的接口不匹配而无法使用。
考虑这个例子：一个绘图编辑器，让用户可以绘制和排列图形元素(线条，多边形，文本，等等。)，来创建图片和图表(diagram)。绘图编辑器的关键的抽象内容是图形对象，是一个可编辑的形状，可以绘制自身。图形对象的接口用一个抽象类Shape来定义。编辑器为每一种图形对象定义一个Shape的子类：LineShape类代表线条, PolygonShape类代表多边形，等等。
表示基本几何形状的类比如LineShape和PolygonShape实现起来还比较容易，因为它们的绘制和编辑功能先天就有限。但是显示和编辑文本的TextShape子类 的实现就要困难一些了，因为即使是很基本的文本编辑都要牵涉到复杂的屏幕更新，缓存管理等问题。同时可能有一个现成的UI工具箱已经提供了非常成熟和专业的TextView类来实现文本的显示和编辑。这种情况下，如果能够直接复用TextView来实现TextShape类当然是最理想的；但是，这个工具箱当初设计的时候并不是为Shape派生类度身订做的。所以我们无法简单地互换使用TextView 对象和Shape 对象。
像TextView这样已经存在的和无关的类怎样才能在期望一个不同和不兼容的接口的应用程式中工作呢?我们可以改变TextView类，让它遵从Shape接口；但是那样做的前提是我们拥有这个工具箱的源代码。即使我们有源代码， 改变TextView类可能也不是一个好主意，工具箱不应该仅仅为了一个应用程式的工作就采用特定问题域的接口。
换个思路，我们可以另外定义一个TextShape类，这个类的任务是将TextView和Shape的接口适配上。具体办法有两种：(1) 继承Shape的接口和extView的实现或者 (2) 把TextView 的实例组合到TextShape 内部，通过调用TextView的接口来实现TextShape 类。这两种办法分别是适配器模式的类实现和对象实现。TextShape类就是一个适配器。
本图表描述了对象适配器的情况。(具体关系看图便知，糊涂熊在此略过。)
值得一提地是，适配器经常还需要负责提供被适配的类所不具备的功能。如上图表所示，用户需要能够拖动任意一个Shape对象到一个新的位置这样一个互动操作。但是TextView的设计用途不是这样的。所以TextShape就需要自己实现Shape类的CreateManipulator 方法来提供这个功能，返回一个相应的Manipulator子类的实例。
Manipulator是一个抽象类，其派生类对象知道如何相应用户的输入来完成Shape的运动(animate)效果，比如拖动到一个新的位置。针对不同Shape， 可以有不同的Manipulato子类。例如TextManipulator就是TextShape的相应子类。通过返回一个TextManipulator 实例, TextShape 添加了TextView缺乏但是Shape 需要的功能。
在以下情形，考虑使用适配器模式：
你要使用一个现成的类(的功能。--糊涂熊注解。)，但是它的接口不完全符合你的需求。
你要创建一个可复用的类来和无关的或者不可预见的其它类协同工作，也就是说，这个可复用的类未必一定要有兼容的接口。(糊涂熊的疑惑：这句话好象不是使用适配器模式的原因，倒有点像结果？) (选择对象适配器的理由) 你需要使用若干现成的子类，但是对每一个子类进行派生来达到适配的目的会显得不太现实，成本太高。这时候选择对象适配器就比较明智，因为对象适配器可以使用父类的接口进行适配。
类适配器可以使用多重继承来适配一个接口到另一个接口：
对象适配器通过对象的组合来达到适配的目的：
Target (Shape)
定义了Client使用的特定于问题域的接口。
Client (DrawingEditor)
与遵循Target 接口的对象协作。
Adaptee (TextView)
定义了一个现成的接口，需要被适配进来。
Adapter (TextShape)
把Adaptee 的接口适配到Target 接口。
[url=http://dev.csdn.net/#consequences][url=file:///D:/myself/tech/Pattern/designpattern/designpattern/hires/gifsb/down3.gif]Collaborations
Clients调用适配器实例的操作，适配器再调用被适配者的操作来完成请求。
