通过for循环遍历一个动态数组，判断用户是否符合条件，对符合条件的用户放置到另外一个数组中，比较简单。我们编写场景类来模拟该情景，如下所示。
运行结果如下所示：
===年龄大于20岁的用户===
用户名：马七 年龄：25
用户名：杨八 年龄：30
用户名：侯九 年龄：35
用户名：布十 年龄：40
结果非常正确，但是这样的一个框架基本上是不能适应业务变化的，为什么呢？业务变化虽然无规则，但是可以预测，比如我们这个查询，今天要查找年龄大于20岁的用户，明天要查找年龄小于30岁的用户，后天要查找姓名中包含“国庆”两个字的用户，想想看IUserProvider接口是不是要一直修改下去？接口是契约，而且我们一直提倡面向接口编程，但是在这里接口竟然都可以修改，是不是发现
设计
领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计
有很大问题了？问题大了！
问题发现了，就要想办法解决。再回顾一下编写的代码，注意看findUserByAgeThan和findUserByNameEqual两个方法，两者的代码有什么地方不同的呢？除了if后面的判断条件不同外，就没有不同的地方了，我们一直在说封装变化，这两段程序就仅仅有这一个变化点，我们是不是可以把它封装起来呢？完全可以，把它们两者的共同点抽取出来，先修改一下接口，如下所示。
public interface IUserProvider {
//根据条件查找用户
public ArrayList
findUser(boolean condition);
}
这个接口的设计想法非常好，但是参数condition很难实现，看看findUserByAgeThan、findUserByNameEqual这两个方法，怎么才能把他们两者的不同点设置成一个布尔型呢？需要在IUserProvider对象外判断后传递进来？那我们的封装就没有任何意义了——目前为止，这个
方案
气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载
有问题了。
继续考虑，既然不能在封装外运算，那就把整个条件都进行封装，由IUserProvider自己实现运算。好方法！那我们就设计一个这样的类，我们叫它规格类，什么意思呢？它是对一批对象的说明性描述，它依照基准判断候选对象是否满足条件。思考后，我们设计出类图，如下所示。
在该类图中建立了一个规格书接口，它的作用就是定制各种各样的规格，比如名字相等的规格UserByNameEqual、年龄大于基准年龄的规格UserByAgeThan等等，然后在用户操作类中采用该规格进行判断。
规格书接口是对全体规格书的声明定义，如下所示。
public interface IUserSpecification {
//候选者是否满足要求
public boolean isSatisfiedBy(User user);
}
规格书接口只定义一个方法，判断候选用户是否满足条件。再来看姓名相同的规格书，它实现了规格书接口，如下所示。
public class UserByNameEqual implements IUserSpecification {
//基准姓名
private String name;
//构造函数传递基准姓名
public UserByNameEqual(String _name){
this.name = _name;
}
//检验用户是否满足条件
public boolean isSatisfiedBy(User user) {
return user.getName().equals(name);
}
}
代码很简单，通过构造函数传递进来基准用户名，然后判断候选用户是否匹配。大于基准年龄的规格书与此类似，如下所示。
public class UserByAgeThan implements IUserSpecification {
//基准年龄
private int age;
//构造函数传递基准年龄
public UserByAgeThan(int _age){
this.age = _age;
}
//检验用户是否满足条件
public boolean isSatisfiedBy(User user) {
return user.getAge() > age;
}
}
规格书都已经定义完毕了，那我们再来看用户操作类，先看用户操作的接口，如下所示。
public interface IUserProvider {
//根据条件查找用户
public ArrayList findUser(IUserSpecification userSpec);
}
只有一个方法——根据指定的规格书查找用户。再来看其实现类，如下所示。
public class UserProvider implements IUserProvider {
//用户列
表
关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf
private ArrayList userList;
//传递用户列表
public UserProvider(ArrayList _userList){
this.userList = _userList;
}
//根据指定的规格查找用户
public ArrayList findUser(IUserSpecification userSpec) {
ArrayList result = new ArrayList();
for(User u:userList){
if(userSpec.isSatisfiedBy(u)){//符合指定规格
result.add(u);
}
}
return result;
}
}
程序改动很小，仅仅在if判断语句中根据规格书进行判断，我们持续地扩展规格书，有多少查询分类就可以扩展出多少个实现类，而IUserProvider则不需要任何改动，它的一个方法就覆盖了我们刚刚提出的N多查询路径。
欲知后事如何，请看下一章节：规格模式 SpecificationPattern 【3】
浙公网安备 33021202002483