封装一些作用于某种数据结构中的各元素的操作，它可以在不改变这个数据结构的前提下定义作用于这些元素的新的操作。

• 对象结构比较稳定，但经常需要在此对象结构上定义新的操作。
• 需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免这些操作”污染“这些对象的类，也不希望在增加新操作时修改这些类。

由上图，适配器模式 主要包含这三种角色：

• Target(目标角色)：该角色定义把其它类转换为何种接口，也就是我们的期望接口。
• Adaptee(源角色)：你想把谁转换成目标角色。
• Adapter(适配器角色)：适配器模式的核心角色，其它两个角色都是已经存在的角色，而适配器角色是需要新建立的，它的职责非常简单，把源角色转换成目标角色，怎么转换?通过继承或类关联的方式。

• 优点：
  • 适配器模式可以让两个没有任何关系得类在一起运行，只要适配器这个角色能够搞定他就成。
  • 增加了类的透明性。我们访问的Target目标角色，但是具体的实现都委托给了源角色，而这些对高层次模块时透明的，也是它不需要关心的。
  • 提高了类的复用度，灵活性非常好
• 缺点：
  • 与类适配器模式相比，要在适配器中置换适配者类的某些方法比较麻烦。如果一定要置换掉适配者类的一个或多个方法，可以先做一个适配者类的子类，将适配者类的方法置换掉，然后再把适配者类的子类当做真正的适配者进行适配，实现过程较为复杂。

ListView 等集合控件通过 Adapter 来获取 Item View 的数量、布局、数据等。 这里的Adapter并不是经典的适配器模式么事对象适配器模式的示例。也是很好的体现了面向对象的一些基本原则。 这里的Target角色就是View、Adapter角色就是将Item View 输出为 View 抽象的角色，Adaptee就是需要被处理的Item View。 通过增加Adapter一层来将ItemView的操作抽象起来，ListView等集合视图通过Adapter对象获取Item的个数、数据、ItemView等，从而达到适配各种数据、各种Item视图的效果。因为ItemView和数据类型千变万化，Android的架构师将这种变化的部分交给用户来处理，通过getCount，getItem，getView等几个抽象出来，也就是将ItemView的构造过程交给用户来处理，灵活地运用了设配器的模式，达到了无限适配，拥抱变化的目的。