1700466761
//从数据库中查到101个
1700466762
1700466763
for（int i=0；i＜101；i++）{
1700466764
1700466765
youngGirl.getMobileNumber（）；
1700466766
1700466767
}
1700466768
1700466769
}
1700466770
1700466771
}
1700466772
1700466773
运行的结果还是相同的。大家想想看，OuterUserInfo变成了委托服务，把IUserInfo接口需要的所有的操作都委托给其他三个接口下的实现类，它的委托是通过对象层次的关联关系进行委托的，而不是继承关系。好了，讲了这么多，我们需要给这种适配器起个名字，就是对象适配器，我们之前讲的通过继承进行的适配，叫做类适配器。对象适配器的通用类图，如图19-9所示。
1700466774
1700466775
1700466776
1700466777
1700466778
图19-9 对象适配器类图
1700466779
1700466780
适配器的通用代码也比较简单，把原有的继承关系变更为关联关系就可以了，不再赘述。对象适配器和类适配器的区别是：类适配器是类间继承，对象适配器是对象的合成关系，也可以说是类的关联关系，这是两者的根本区别。二者在实际项目中都会经常用到，由于对象适配器是通过类间的关联关系进行耦合的，因此在设计时就可以做到比较灵活，比如修补源角色的隐形缺陷，关联其他对象等，而类适配器就只能通过覆写源角色的方法进行扩展，在实际项目中，对象适配器使用到场景相对较多。
1700466781
1700466782
1700466783
1700466784
1700466785
设计模式之禅 [:1700454006]
1700466786
设计模式之禅 19.5 最佳实践
1700466787
1700466788
适配器模式是一个补偿模式，或者说是一个“补救”模式，通常用来解决接口不相容的问题，在百分之百的完美设计中是不可能使用到的，什么是百分之百的完美设计？“千虑”而没有“一失”的设计，但是，再完美的设计也会遇到“需求”变更这个无法逃避的问题，就以我们上面的人力资源管理系统为例来说，不管系统设计得多么完美，都无法逃避新业务的发生，技术只是一个工具而已，是因为它推动了其他行业的进步和发展而具有了价值，通俗地说，技术是为业务服务的，因此业务在日新月异变化的同时，也对技术提出了同样的要求，在这种要求下，就需要我们有一种或一些这样的补救模式诞生，使用这些补救模式可以保证我们的系统在生命周期内能够稳定、可靠、健壮的运行，而适配器模式就是这样的一个“救世主”，它在需求巨变、业务飞速而导致你极度郁闷、烦躁、崩溃的时候横空出世，它通过把非本系统接口的对象包装成本系统可以接受的对象，从而简化了系统大规模变更风险的存在。
1700466789
1700466790
1700466791
1700466792
1700466793
设计模式之禅 [:1700454007]
1700466794
设计模式之禅 第20章 迭代器模式
1700466795
1700466796
设计模式之禅 [:1700454008]
1700466797
20.1 整理项目信息——苦差事
1700466798
1700466799
周五下午，我正在看技术网站，第六感官发觉有人在身后，扭头一看，老大站在背后，我赶忙站起来。
1700466800
1700466801
“王经理，你找我？”
1700466802
1700466803
“哦，在看技术呀。有个事情找你谈一下，你到我办公室来一下。”
1700466804
1700466805
到老大办公室还没坐稳，老大就开始发话了。
1700466806
1700466807
“是这样，刚刚我在看季报，我们每个项目的支出费用都很高，项目情况复杂，人员情况也不简单，我看着也有点糊涂，你看，这是我们现在还在开发或者维护的103个项目，项目信息很乱，很多是两年前的信息，你能不能先把这些项目最新情况重新打印一份给我，咱们好查查到底有什么问题。”老大说。
1700466808
1700466809
“这个好办，我马上去办！”我爽快地答复道。
1700466810