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
1700466511
代码清单19-13 用户基本信息接口
1700466512
1700466513
public interface IOuterUserBaseInfo{
1700466514
1700466515
//基本信息，比如名称、性别、手机号码等
1700466516
1700466517
public Map getUserBaseInfo（）；
1700466518
1700466519
}
1700466520
1700466521
用户家庭信息接口如代码清单19-14所示。
1700466522
1700466523
代码清单19-14 用户家庭信息接口
1700466524
1700466525
public interface IOuterUserHomeInfo{
1700466526
1700466527
//用户的家庭信息
1700466528