1700483606
1700483607
userList.add（new User（“王五”，18））；
1700483608
1700483609
userList.add（new User（“赵六”，20））；
1700483610
1700483611
userList.add（new User（“马七”，25））；
1700483612
1700483613
userList.add（new User（“杨八”，30））；
1700483614
1700483615
userList.add（new User（“侯九”，35））；
1700483616
1700483617
userList.add（new User（“布十”，40））；
1700483618
1700483619
//定义一个用户查询类
1700483620
1700483621
IUserProvider userProvider=new UserProvider（userList）；
1700483622
1700483623
//打印出年龄大于20岁的用户
1700483624
1700483625
System.out.println（”===年龄大于20岁的用户===”）；
1700483626
1700483627
for（User u：userProvider.findUserByAgeThan（20））{
1700483628
1700483629
System.out.println（u）；
1700483630
1700483631
}
1700483632
1700483633
}
1700483634
1700483635
}
1700483636
1700483637
运行结果如下所示：
1700483638
1700483639
===年龄大于20岁的用户===
1700483640
1700483641
用户名：马七年龄：25
1700483642
1700483643
用户名：杨八年龄：30
1700483644
1700483645
用户名：侯九年龄：35
1700483646
1700483647
用户名：布十年龄：40
1700483648
1700483649
结果非常正确，但是这样的一个框架基本上是不能适应业务变化的，为什么呢？业务变化虽然无规则，但是可以预测，比如我们这个查询，今天要查找年龄大于20岁的用户，明天要查找年龄小于30岁的用户，后天要查找姓名中包含“国庆”两个字的用户，想想看IUserProvider接口是不是要一直修改下去？接口是契约，而且我们一直提倡面向接口编程，但是在这里接口竟然都可以修改，是不是发现设计有很大问题了！
1700483650
1700483651
问题发现了，就要想办法解决。再回顾一下编写的代码，注意看findUserByAgeThan和findUserByNameEqual两个方法，两者的代码有什么不同呢？除了if后面的判断条件不同外，就没有不同的地方了，我们一直在说封装变化，这两段程序就仅仅有这一个变化点，我们是不是可以把它封装起来呢？完全可以，把它们两者的共同点抽取出来，先修改一下接口，如代码清单37-5所示。
1700483652
1700483653
代码清单37-5 修正后的接口
1700483654
1700483655
public interface IUserProvider{
[
上一页 ]
[ :1.700483606e+09 ]
[
下一页 ]