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
1700484170
this.name=_name；
1700484171
1700484172
}
1700484173
1700484174
//检验用户是否满足条件
1700484175
1700484176
public boolean isSatisfiedBy（User user）{
1700484177
1700484178
return user.getName（）.equals（name）；
1700484179
1700484180
}
1700484181
1700484182
}
1700484183
1700484184
仅仅修改了黑体部分，其他没有任何改变。另外两个规格书修改相同，不再赘述。其他的User及UserProvider没有任何改动，不再赘述。
1700484185
1700484186
我们修改一下场景类，如代码清单37-21所示。
1700484187
1700484188
代码清单37-21 场景类
1700484189
1700484190
public class Client{
1700484191
1700484192
public static void main（String[]args）{
1700484193
1700484194
//首先初始化一批用户
1700484195
1700484196
ArrayList＜User＞userList=new ArrayList＜User＞（）；
1700484197
1700484198
userList.add（new User（“苏国庆”，23））；
1700484199
[
上一页 ]
[ :1.70048415e+09 ]
[
下一页 ]