1700483950
===名字包含国庆的人员===
1700483951
1700483952
用户名：苏国庆 年龄：23
1700483953
1700483954
用户名：国庆牛 年龄：82
1700483955
1700483956
用户名：张国庆三 年龄：10
1700483957
1700483958
到目前为止，我们已经设计了一个可扩展的对象查询平台，但是我们还有遗留问题未解决，看看SQL语句，为什么where后面会很长？是因为有AND、OR、NOT这些逻辑操作符的存在，它们可以串联起多个判断语句，然后整体反馈出一个结果来。想想看，我们上面的平台能支持这种逻辑操作符吗？不能，你要说能，那也说得通，需要两次过滤才能实现，比如要找名字包含“国庆”并且年龄大于25岁的用户，代码该怎么修改？如代码清单37-14所示。
1700483959
1700483960
代码清单37-14 复合查询
1700483961
1700483962
public class Client{
1700483963
1700483964
public static void main（String[]args）{
1700483965
1700483966
//定义一个规格书
1700483967
1700483968
IUserSpecification userSpec1=new UserByNameLike（”%国庆%”）；
1700483969
1700483970
IUserSpecification userSpec2=new UserByAgeThan（20）；
1700483971
1700483972
userList=userProvider.findUser（userSpec1）；
1700483973
1700483974
for（User u：userProvider.findUser（userSpec2））{
1700483975
1700483976
System.out.println（u）；
1700483977
1700483978
}
1700483979
1700483980
}
1700483981
1700483982
}
1700483983
1700483984
能够实现，但是思考一下程序逻辑，它采用了两次过滤，也就是两次循环，如果对象数量少还好说，如果对象数量巨大，这个效率就太低了，这是其一；其二，组合方式非常多，比如“与”、“或”、“非”可以自由组合，姓名中包含“国庆”但年龄小于25的用户，姓名中不包含国庆但年龄大于25岁的用户等等，我们还能如此设计吗？太多的组合方式，产生组合爆炸，这种设计就不妥了，应该有更优秀的方案。
1700483985
1700483986
我们换个方式思考该问题，不管是AND或者OR或者NOT操作，它们的返回结果都还是一个规格书，只是逻辑更复杂了而已，这3个操作符只是提供了对原有规格书的复合作用，换句话说，规格书对象之间可以进行与或非操作，操作的结果不变，分析到这里，我们就可以开始修改接口了，如代码清单37-15所示。
1700483987
1700483988
代码清单37-15 带与或非的规格书接口
1700483989
1700483990
public interface IUserSpecification{
1700483991
1700483992
//候选者是否满足要求
1700483993
1700483994
public boolean isSatisfiedBy（User user）；
1700483995
1700483996
//and操作
1700483997
1700483998
public IUserSpecification and（IUserSpecification spec）；
1700483999
[
上一页 ]
[ :1.70048395e+09 ]
[
下一页 ]