打字猴:1.70048395e+09
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 ]  [ 下一页 ]