1700466461
设计模式之禅 [:1700454004]
1700466462
设计模式之禅 19.3 适配器模式的应用
1700466463
1700466464
19.3.1 适配器模式的优点
1700466465
1700466466
❑适配器模式可以让两个没有任何关系的类在一起运行，只要适配器这个角色能够搞定他们就成。
1700466467
1700466468
❑增加了类的透明性
1700466469
1700466470
想想看，我们访问的Target目标角色，但是具体的实现都委托给了源角色，而这些对高层次模块是透明的，也是它不需要关心的。
1700466471
1700466472
❑提高了类的复用度
1700466473
1700466474
当然了，源角色在原有的系统中还是可以正常使用，而在目标角色中也可以充当新的演员。
1700466475
1700466476
❑灵活性非常好
1700466477
1700466478
某一天，突然不想要适配器，没问题，删除掉这个适配器就可以了，其他的代码都不用修改，基本上就类似一个灵活的构件，想用就用，不想就卸载。
1700466479
1700466480
1700466481
1700466482
1700466483
设计模式之禅 19.3.2 适配器模式的使用场景
1700466484
1700466485
适配器应用的场景只要记住一点就足够了：你有动机修改一个已经投产中的接口时，适配器模式可能是最适合你的模式。比如系统扩展了，需要使用一个已有或新建立的类，但这个类又不符合系统的接口，怎么办？使用适配器模式，这也是我们例子中提到的。
1700466486
1700466487
1700466488
1700466489
1700466490
设计模式之禅 19.3.3 适配器模式的注意事项
1700466491
1700466492
适配器模式最好在详细设计阶段不要考虑它，它不是为了解决还处在开发阶段的问题，而是解决正在服役的项目问题，没有一个系统分析师会在做详细设计的时候考虑使用适配器模式，这个模式使用的主要场景是扩展应用中，就像我们上面的那个例子一样，系统扩展了，不符合原有设计的时候才考虑通过适配器模式减少代码修改带来的风险。
1700466493
1700466494
再次提醒一点，项目一定要遵守依赖倒置原则和里氏替换原则，否则即使在适合使用适配器的场合下，也会带来非常大的改造。
1700466495
1700466496
1700466497
1700466498
1700466499
设计模式之禅 [:1700454005]
1700466500
设计模式之禅 19.4 适配器模式的扩展
1700466501
1700466502
我们刚刚讲的人力资源管理的例子中，其实是一个比较幸运的例子，为什么呢？如果劳动服务公司提供的人员接口不止一个，也就是说，用户基本信息是一个接口，工作信息是一个接口，家庭信息是一个接口，总共有三个接口三个实现类，想想看如何处理呢？不能再使用我们上面的方法了，为什么呢？Java是不支持多继承的，你难道想让OuterUserInfo继承三个实现类？此路不通，再想一个办法，对哦，可以使用类关联的办法嘛！声明一个OuterUserInfo实现类，实现IUserInfo接口，通过再关联其他三个实现类不就可以解决这个问题了吗？是的，是的，好方法，我们先画出类图，如图19-8所示。
1700466503
1700466504
1700466505
1700466506
1700466507
图19-8 拆分接口后的类图
1700466508
1700466509
OuterUserInfo通过关联的方式与外界的三个实现类通讯，当然也可以理解为是聚合关系。IUserInfo和UserInfo代码如代码清单19-1和代码清单19-2所示，不再赘述。我们来看看拆分后的三个接口和实现类，用户基本信息接口如代码清单19-13所示。
1700466510