拦截过滤器模式实现场景下是否应当使用NullValueFilter？

结论先行 #

你的思路方向完全合理，不属于过度设计。你当前15~20个过滤器都重复实现了空值/空列表校验逻辑，已经出现了明显的代码冗余，做统一处理的收益远高于投入。

核心问题解答 #

1. 是否需要单独在过滤器链中使用NullValueFilter？ #

单独放在链头只能覆盖初始输入为空的场景，无法覆盖中间过滤后列表变空的情况，所以只加全局的NullValueFilter不能完全解决问题，还是需要在每个过滤器执行前做空校验。

2. 两种可选方案的对比 #

优先选方案1：FilterBase基类统一处理，这是最轻量化、最高效的实现方式，用模板方法模式就能搞定：

abstract class FilterBase : IFilter {
  // 模板方法：统一执行公共校验 + 子类业务逻辑
  public bool Execute(List<CampaignList> campaignList) {
    // 公共空校验逻辑，所有子类复用
    if(campaignList == null || campaignList.Count == 0) {
      return false;
    }
    // 调用子类实现的具体过滤逻辑
    return FilterCore(campaignList);
  }

  // 子类只需要实现各自的过滤规则，不需要再写空校验
  protected abstract bool FilterCore(List<CampaignList> campaignList);
}

// 子类实现示例
class PlatformFilter : FilterBase {
  protected override bool FilterCore(List<CampaignList> campaignList) {
    campaignList = campaignList.Where( x => x.Platform == "Mobile").ToList();
    return true;
  }
}

这种方式完全消除了重复代码，后续如果要调整空校验规则，只需要修改基类一处即可，维护成本极低。

而方案2：注入NullValueFilter到每个过滤器属于冗余设计，会额外增加所有过滤器的依赖复杂度，完全可以用基类实现的逻辑没必要引入额外依赖。

3. 是否需要用策略模式注入空校验逻辑？ #

如果你的空校验规则未来会有多种变化（比如部分场景下空列表不需要中断链执行、不同业务线空校验规则不同），可以把空校验抽成独立的校验策略接口，注入到FilterBase中统一调用，不需要每个过滤器单独注入。
如果空校验规则长期只有一种，就不需要额外引入策略模式，直接写在基类中即可。

关于是否过度设计的判断 #

你当前已经有20个左右的过滤器，重复的空校验逻辑已经存在20份，现在做统一优化属于合理的架构收敛，不是过度设计。哪怕后续只新增几个过滤器，这种实现也能大幅降低后续的维护成本。

内容的提问来源于stack exchange，提问作者Sanjay Soni