前言
在之前的文章中已经向大家介绍了策略模式的使用,在本期中我向大家介绍另外一种设计模式------过滤器模式。 大家看名字就应该清楚 过滤器模式就是用来过滤数据的,与策略模式不同,过滤器模式属于结构型模式,这种模式允许开发人员使用不同的 标准来过滤一组对象,通过运算逻辑以解耦的方式将它们连接起来。过滤器模式可结合多个标准来获得单一标准。简单点说就是用不同的规则来过滤数据。 在过滤器模式中。主要有三种角色
- 抽象过滤器
抽象过滤器即定义了各个规则下过滤的原则 - 具体过滤器 具体过滤器则针对每一种情况对其进行过滤
- 被过滤对象 过滤对象即是过滤的主体内容
上面这张图就表示了这种关系 在接口中定义了一个过滤的方法,具体的实现通过其实现类的规则来进行过滤,过滤的内容就是context
筛选老师-过滤器模式
下面我们来举一个例子,让大家能更清楚的了解过滤器模式的思想,假设我们要向外提供一个方法,为课程找到适合上课的老师。由于每个课的时间不同,科目不同,我们很难在一个方法中实现。首先我们按照上面的方法来实现
java
interface TeacherFilter{
TeacherContext filter(TeacherContext context);
}
class TeacherSubjectFilter implent TeacherFilter{
TeacherContext filter(TeacherContext context){
// 科目过滤
}
}
class TeacherTimeConfiltFilter implent TeacherFilter{
TeacherContext filter(TeacherContext context){
// 时间冲突过滤
}
}
这样 我们定义了一个抽象的规则和两个具体的实现。 在TeacherContext中可以有这样一些属性
- 待筛选的老师集合
- 是否满足条件
- 筛选所需的其余条件
这样在每个实现中只需要执行过滤,返回数据就可以。 但还要考虑一个问题,就是后续过滤规则越来越多,则会使代码的可读性下降。
java
Enum filterRule{
MATH_RULE{
SubjectFilter();
TimeFilter();
}
SPORTS_RULE{
SubjectFilter();
TimeFilter();
AgeFilter();
}
}
我们可以定义一个枚举 每一个大类代表一类筛选规则 ,其中记录了对应的实现,比如如果找一位体育老师,需要科目过滤,时间过滤,年龄过滤,这样,代码的可维护性就会上一个档次
注意点
首先 在定义具体过滤器时应对使用尽可能低的粒度。这样在对具体实现进行改动时,对现有逻辑的影响最小,不然改了一个也影响了其他的,反而是一种麻烦。 其次,要考虑的在使用中由于过滤实现的不断增加,导致使用方很难一次梳理需要哪些规则进行过滤,在对外暴露接口时 应尽可能规范,或将封装好的过滤接口对外暴露。在本身的使用中也应该有一个地方统一管理这些过滤规则,例如在上面的例子在使用的枚举将不同的规则进行了分类。在对某一种大类的规则修改时简单易懂,甚至不需看具体实现 只看使用了哪些过滤的枚举就大概清楚整体的逻辑 最后,还要考虑到整体的实现越来越多,需要的条件也越来越多,最终可能会导致整体接口变得慢,这时需要考虑条件判断,提前返回,提高接口的效率