《设计模式之禅》之适配器模式
适配器模式的定义
将一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。
适配器模式的三个角色:
1.Target目标角色
该角色定义把其他类转换为何种接口，也就是我们的期望接口。
2.Adapter源角色
你想把谁转换成目标角色，这个”谁”就是源角色，它是已经存在的、运行良好的类或对象，经过适配器角色的包装，它会成为一个崭新、靓丽的角色。
3.Adapter适配器角色
适配器模式的核心角色，其他两个角色都是已经存在的角色，而适配器角色是需要新建立的，它的职责非常简单:把源角色转换为目标角色，怎么转换?通过继承或是类关联的方式。
适配器模式的应用
1.适配器模式的优点
- 适配器模式可以让两个没有任何关系的类在一起运行，只要适配器这个角色能够搞定他们就成。
- 增加类的透明性(我们访问的Target目标角色，但是具体的实现都委托给源角色，而这些对高层次模块是透明的，也是它不需要关心的)
- 提高类的复用度(源角色在原有的系统中还是可以正常使用，而在模板角色中也可以充当新的演员)
- 灵活性非常好(某一天，突然不想要适配器，没问题，删除掉这个适配器就可以了，其他的代码都不用修改，基本上就类似一个灵活地构件，想用就用，不用就卸载)
2.适配器模式的使用场景
适配器应用的场景只要记住一点:
你有动机修改一个已经投产中的接口时，适配器模式可能是最适合你的模式。
比如系统扩展了，需要使用一个已有或新建立的类，但这个类又不符合系统的接口？这时使用适配器模式就能解决这个问题。
3.适配器模式的注意事项
适配器模式最好在详细设计阶段不要考虑它，它不是为了解决还处在开发阶段的问题，而是解决正在服役的项目问题，没有一个系统分析师会在做详细设计的时候考虑使用适配器模式。
着重提醒:项目一定要遵守依赖倒置原则和里氏替换原则，否则即使在适合使用适配器的场合下，也会带来非常大的改造。
最佳实践
适配器模式是一个补偿模式，或者说是一个”补救”模式，通常用来解决接口不相容的问题，在百分之百的完美设计中是不可能使用到的。但是实际中是不可能出现这样的设计。
不管系统设计得多么完美，都无法逃避新业务的发生，技术只是一个工具而已，是因为它推动了其他行业的进步和发展而具有价值，通俗地说，技术是为业务服务的，因此业务在日新月异的同时，也对技术提出了同样的要求，在这种要求下，就需要我们有一种或一些这样的补救模式诞生，使用这些补救模式可以保证我们的系统在生命周期内能够稳定、可靠、健壮的运行，而适配器模式就是这样的一个”救世主”，它在需求巨变、业务飞速而导致你极度郁闷、烦躁、崩溃的时候横空出世，它通过把非本系统接口的对象包装成本系统可以接受的对象，从而简化了系统大规模变更风险的存在。
代码例子:
https://github.com/developers-youcong/DesignPatternPractice/tree/master/Adapter