打字猴:1.70048412e+09
1700484120 public boolean isSatisfiedBy(User user){
1700484121
1700484122 return left.isSatisfiedBy(user)||right.isSatisfiedBy(user);
1700484123
1700484124 }
1700484125
1700484126 }
1700484127
1700484128 代码清单37-19 非规格书
1700484129
1700484130 public class NotSpecification extends CompositeSpecification{
1700484131
1700484132 //传递一个规格书
1700484133
1700484134 private IUserSpecification spec;
1700484135
1700484136 public NotSpecification(IUserSpecification_spec){
1700484137
1700484138 this.spec=_spec;
1700484139
1700484140 }
1700484141
1700484142 //not操作
1700484143
1700484144 @Override
1700484145
1700484146 public boolean isSatisfiedBy(User user){
1700484147
1700484148 return!spec.isSatisfiedBy(user);
1700484149
1700484150 }
1700484151
1700484152 }
1700484153
1700484154 这三个规格书都是不发生变化的,只要使用该框架,三个规格书都要实现的,而且代码基本上是雷同的,所以才有了父类依赖子类的设计,否则是严禁出现父类依赖子类的情况的。大家再仔细看看这三个规格书和组合规格书,代码很简单,但也很巧妙,它跳出了我们面向对象设计的思维,不变部分使用一种固化方式实现。
1700484155
1700484156 姓名相同、年龄大于基准年龄、Like格式等规格书都有少许改变,把实现接口变为继承基类,我们以名字相等规格书为例,如代码清单37-20所示。
1700484157
1700484158 代码清单37-20 姓名相同规格书
1700484159
1700484160 public class UserByNameEqual extends CompositeSpecification{
1700484161
1700484162 //基准姓名
1700484163
1700484164 private String name;
1700484165
1700484166 //构造函数传递基准姓名
1700484167
1700484168 public UserByNameEqual(String_name){
1700484169
[ 上一页 ]  [ :1.70048412e+09 ]  [ 下一页 ]