Should We use NullValueFilter in Intercept Design Pattern Implementation?

Question

I have a List of campaigns that need to be processed via different kinds of filters for e.g., Platform Filter, Application Filter, CampaignRunning Filter to check if the current date should be between Start Date and End Date etc.

There are ideally 15 - 20 different filters, and I am managing them using Intercept Design Pattern.

before applying filters List could be empty, so should I use NullValueFilter in the filter chain?

after applying some filters list again can be empty, to check that also should I inject the same null or empty check strategy using the strategy design pattern?

I usually think more on designing perspective to manage such cases. I want to know if I am thinking in the right direction or maybe I am overengineering on that part.

Some pseudo code to illustrate the scenario -

Class NullValueFilter : IFilter {
  Execute(List<CampaignList> campaignList) {
    if(campaignList != null && campaignList.Count == 0) {
         return false;
    }
    return true;
  }
}

Class PlatformFilter : IFilter {
  Execute(List<CampaignList> campaignList) {
    if(campaignList != null && campaignList.Count == 0) {
         return false;
    }
    campaignList = campaignList.Where( x => x.Platform == 'Mobile');
    return true
  }
}

Class CampaignRunningFilter : IFilter {
  Execute(List<CampaignList> campaignList) {
    if(campaignList != null && campaignList.Count == 0) {
         return false;
    }
    // first Fetch campaign start date and end date 
    
    campaignList = campaignList.Where( x => x.startdate <= curr_date && x.enddate >= curr_date);
    return true
  }
}

I can think of two options here -

create a filterbase class that can manage null and empty check for list.
inject null value filter instance in each filter using constructor injection and call that null and empty check method.

Ok, I see that your "null value filter" does not filter anything, it just checks for the empty list, returning either true or false. But how will this be used to affect the filtering? — Doc Brown, Oct 06 '21 at 10:00
... and second question: why are all these checks for the empty list required at all? It looks to me as if all these filters would be working perfectly without the checks: empty list in gives empty list out. — Doc Brown, Oct 06 '21 at 10:02
First, the Null Value Filter will only check for null and decide whether the next filter should be executed or break the chain. Second, I just want to avoid the next chain of filters to execute on the empty list. — Sanjay Soni, Oct 06 '21 at 12:09

Doc Brown · Accepted Answer · 2021-10-06T14:45:42.783

For 15 up to 20 filters, I would simply not do any checks for the empty list, that makes things more complicated than necessary without any noteable benefit.

Each filter behaves perfectly consistent when it passes an empty list just through, so I don't see any compelling reason why this premature optimization of "breaking the chain" is necessary. The most cleanest design is IMHO the one where we have thrown any unneccesary waste over board, so this is what I would start with.

However, if you really notice measureable, relevant performance improvement by stopping the processing at the empty list, I would not let the filters test for this case. Instead, let the caller test it directly, instead of checking a boolean return code. I would recommend to make the Execute method return the filtered list, and do implement it along the lines of this snippet:

 List<Campaign> campaignList = ...;  // init this here
 foreach(IFilter filter in GetActiveFilters)
 {
      if(campaignList==null || campaignList.Count == 0)
          break;
      campaignList = filter.Execute(campaignList);
 }

This way, there is only one place in the code where the empty-list test needs to be implemented, and you don't have to repeat this in the filters over and over again.

score 1 · Answer 2 · answered Oct 06 '21 at 14:39

can we create an abstract class that will expose a public method Execute that will be responsible for calling another protected abstract method lets say ExecuteFilter and call it conditionally and all filters will implement this abstract class eg:

Class AbstractBaseFilterClass : IFilter {
    public Execute(List<CampaignList> campaignList) {
    if(campaignList != null && campaignList.Count == 0) {
         return false;
       }
      ExecuteFilter(campaignList);
   }
   protected abstract boolean ExecuteFilter(List<CampaignList> campaignList);
}


Class PlatformFilter : AbstractBaseFilterClass {
  ExecuteFilter(List<CampaignList> campaignList) {
    if(campaignList != null && campaignList.Count == 0) {
         return false;
    }
    campaignList = campaignList.Where( x => x.Platform == 'Mobile');
    return true
  }
}

Class CampaignRunningFilter : AbstractBaseFilterClass {
  ExecuteFilter(List<CampaignList> campaignList) {
    if(campaignList != null && campaignList.Count == 0) {
         return false;
    }
    // first Fetch campaign start date and end date 
    
    campaignList = campaignList.Where( x => x.startdate <= curr_date && x.enddate >= curr_date);
    return true
  }
}

// client can call it simply
 List<Campaign> campaigns = ...;
 foreach(IFilter filter in Filters)
 {
     filter.Execute(campaignList);
 }

Should We use NullValueFilter in Intercept Design Pattern Implementation?

2 Answers2