适配器模式，外观模式
适配器模式
定义：适配器模式将一个类的接口，转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间。
两种实现方式：
- 对象适配器 ,使用组合关系来实现
- 类适配器 ,使用继承关系来实现。
到底该如何选择使用哪一种呢？判断的标准主要有两个，一个是 Adaptee ( 被适配 ) 接口的个数，另一个是 Adaptee 和 ITarget 的契合程度。
- 如果 Adaptee 接口并不多，那两种实现方式都可以。
- 如果 Adaptee 接口很多，而且 Adaptee 和 ITarget 接口定义大部分都相同，那我们推荐使用类适配器，因为 Adaptor 复用父类 Adaptee 的接口，比起对象适配器的实现方式，Adaptor 的代码量要少一些。
- 如果 Adaptee 接口很多，而且 Adaptee 和 ITarget 接口定义大部分都不相同，那我们推荐使用对象适配器，因为组合结构相对于继承更加灵活。
一般来说，适配器模式可以看作一种“补偿模式”，用来补救设计上的缺陷。应用这种模式算是“无奈之举”，如果在设计初期，我们就能协调规避接口不兼容的问题，那这种模式就没有应用的机会了。
- 封装有缺陷的接口设计
- 统一多个类的接口设计
- 替换依赖的外部系统
- 兼容老版本接口
- 适配不同格式的数据
问题：
1）一个适配器只能封装一个类吗？
适配器工作是将一个接口转换成另一个。对于复杂的现实世界，为了解决问题我们可以让一个适配器包装多个被适配者。这涉及另一个模式--外观模式。
2）如果系统中新旧并存，旧部分期望旧厂商接口，但是我们已经使用了新厂商的接口编写了一部分，这时候该怎么办？
这里使用适配器，那里却使用未包装的接口。 我们可以创建一个双向适配器，支持两边的接口。双向适配器实现了两个接口，这样就可以当旧的接口，或者当新的接口使用。
外观模式
定义：外观模式提供一个同一的接口，用来访问系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。
接口粒度设计太大会导致接口不可复用，太小会导致接口不易用。
接口的可复用性和易用性需要“微妙”的权衡。尽量保持接口的可复用性，但针对特殊情况，允许提供冗余的门面接口，来提供更易用的接口。
要点：
1）外观不只是简化了接口，也将客户从组件的子系统中解耦。
2）外观和适配器可以包装许多类，但是外观的意图是简化接口，而适配器的意图是将接口转化成不同接口。
应用场景：
- 解决易用性问题
- 解决性能问题：如客户端通过网络通信调用三个接口完成加载一个页面，统一成调用一个接口。减少连接和网络通信。
- 解决分布式事务问题：如创建用户同时创建钱包，设计一个包裹这两个操作的新接口，让新接口在一个事务中执行两个 SQL 操作。（分布式事务框架或者事后补偿的机制相对比较复杂）
设计原则：“最少知识”原则 ，该原则告诉我们要减少对象之间的交互，只和你的密友谈话。（此原则减少了对象之间的依赖，研究显示这会减少软件的维护成本；但是也会导致更多的“包装”类被制造，以处理和其他组件的沟通，这可能会导致复杂度和开发时间的增加，并降低运行时的性能。）
