从真实项目中抠出来的设计模式——第二篇：过滤器模式

? ? ?我们在给用户做订单催付通知的时候，会有这样的一种场景，用户在系统后台设置一组可以催付的规则，比如说订单金额大于xx元，非黑名单用户，来自

哪个地区，已购买过某个商品，指定某个营销活动的人等等这样的条件，如果这时用户在淘宝上下了一个订单，那程序要判断的就是看一下此订单是否满足这

些规则中的某一个，如果满足，我们给他发送催付通知，这种场景是很多做CRM的同学都会遇到的问题，那针对这种场景，如何更好的规划业务逻辑呢？

? ? 在这里我们就不考虑多筛选条件下的性能，而只从代码维护复杂度考虑，如果不清楚设计模式的同学，大概会写出如下的代码：

? ? ?为了演示，上面的代码是从regularid，regularname，condition三个维度对regulars这个聚合对象进行AND模式的筛选过滤，当过滤维度比较多的时候，这种写

法看的出来是简单粗暴，维护起来也必须简单粗暴， 所以上万行代码也就是这么出来的，设计模式告诉我们一个简单的“开闭原则”，那就是追求最小化的修改代码，这种

场景有更好的优化策略吗？对应到设计模式上就是“过滤器模式”，专门针对这种场景的解决方案，一个维度一个类，然后通过逻辑运算类将他们进行组合，可以看出这是一

种“结构式的设计模式”。

? ?好了，废话不多说，先来看一下优化后的设计图纸如下：

从上面这张图纸中可以看到，我已经将三个维度的过滤方法提取成了三个子类，由此抽象出了一个IFilter接口，当然你也可以定义成抽象类，然后实现了两个运算级

AND和OR子类Filter，用于动态的对原子性的RegularIDFilter,RegularNameFilter，ReuglarCondtionFilter进行AND,OR逻辑运算，下面我们再看具体代码：

当你仔细看完上面的代码，会不会发现，如果后续有需求变更，比如说增加筛选的维度，我只需要新增一个继承IFilter的子类就搞定了，客户端在调用的时候只要

在Filters集合中追加该筛选维度，是不是就OK了，所以这种模式几乎达到了无代码修改的地步~~~好了，本篇就说到了这里，希望对你有帮助~

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!