本文节选自《设计模式就该这样学》
我们使用适配模式来实现一个实际的业务场景，解决实际问题。年纪稍微大一点的小伙伴一定经历过这样的过程。很早以前开发的老系统应该都有登录接口，但是随着业务的发展和社会的进步，单纯地依赖用户名密码登录显然不能满足用户需求。现在，大部分系统都已经支持多种登录方式，如qq登录、微信登录、手机登录、微博登录等，同时保留用户名密码的登录方式。虽然登录形式丰富，但是登录后的处理逻辑可以不必改，都是将登录状态保存到session，遵循开闭原则。首先创建统一的返回结果resultmsg类。
假设在老系统中，处理登录逻辑的代码在passportservice类中。
为了遵循开闭原则，不修改老系统的代码。下面开启代码重构之路，创建member类。
我们也不改动运行非常稳定的代码，创建target角色ipassportforthird接口。
创建adapter角色实现兼容，创建一个新的类passportforthirdadapter，继承原来的逻辑。
客户端测试代码如下。
通过这么一个简单的适配动作，我们完成了代码兼容。当然，代码还可以更加优雅，根据不同的登录方式，创建不同的adapter。首先创建loginadapter接口。
然后创建一个抽象类abstractadapter继承passportservice原有的功能，同时实现iloginadapter接口，再分别实现不同的登录适配，qq登录loginforqqadapter。
手机登录loginforteladapter。
token自动登录loginfortokenadapter。
微信登录loginforwechatadapter。
接着创建适配器passportforthirdadapter类，实现目标接口ipassportforthird完成兼容。
最后来看如下图所示的类图。
至此，在遵循开闭原则的前提下，我们完整地实现了一个兼容多平台登录的业务场景。当然，目前的这个设计并不完美，仅供参考，感兴趣的小伙伴们可以继续完善这段代码。例如适配器类中的参数目前是设置为string，改为object[]应该更合理。
学习到这里，相信小伙伴们会有一个疑问：适配器模式与策略模式好像区别不大？我要强调一下，适配器模式主要解决的是功能兼容问题，单场景适配可能不会和策略模式有对比。但复杂场景适配大家就很容易混淆。其实，大家有没有发现一个细节，笔者给每个适配器类都加上了一个support()方法，用来判断是否兼容，support()方法的参数类型也是object，而support()来自接口。适配器类的实现逻辑并不依赖接口，完全可以将iloginadapter接口去掉。而加上接口，只是为了代码规范。上面代码可以说是策略模式、简单工厂模式和适配器模式的综合运用。
【推荐】tom弹架构：收藏本文，相当于收藏一本“设计模式”的书 本文为“tom弹架构”原创，转载请注明出处。技术在于分享，我分享我快乐！ 如果本文对您有帮助，欢迎关注和点赞；如果您有任何建议也可留言评论或私信，您的支持是我坚持创作的动力。关注微信公众号『 tom弹架构 』可获取更多技术干货！