适配器模式
如需要集成多种第三方支付接口的api，但是第三方接口不统一，微信的api是一套，支付宝的又是另外一套。在业务逻辑中，需要通过if else 去进行判断，后续有新的第三方接口时需要修改业务逻辑，新增if语句。
- PaymentService去统一兼容不同支付方式,提供了各种process,pay接口用一堆if
- 新增支付方式时,增加对应的方法,pay中增加if语句 违背开闭原则(需要修改PaymentService),影响代码的稳定性
- 调用方在使用时:不一定需要这么多的支付方式,代码冗余
使用适配器模式
- 使用一个list存放支付方式,pay中遍历list找到需要的支付方式
- 调用方自己决定需要那些支付方式,在adapter添加然后调用即可
- 添加新支付方式时只要添加新类即可
何时使用适配器模式?
- 当需要集成第三方库或遗留系统，但接口不兼容时，如例子中支付场景
- 现有类的接口与调用端期望的接口不匹配,可以用适配器模式
- 为不同版本的API提供统一的接口
- 想要复用一些现有的类，但其接口不符合当前需求
- 统一的接口实现，但是有些场景不需要实现所有的功能都(功能拆分)，可以通过适配器模式拆分接口功能，让具体功能的代码更加清晰，如netty的handler
