Question

I have a scenario where I am processing a queue of MailItems. Once I have processed each MailItem, I need to update the Status of the MailItem. The logic for updating the status is quite complex. My thinking is that I should not encapsulate the logic itself inside the MailItem class, but rather encapsulate it in a separate class for future ease of maintenance.

My question, therefore, is what is the best way to do this?

I considered the Specification Pattern. My research on this pattern is that it hinges on the ISpecification interface defined as follows:

public interface ISpecification<T>
{
   bool IsSatisfiedBy(T candidate);
}

My problem is that my logic in this particular case is influenced not only by the internal state of the candidate object, but also by an external value that I need to pass in for consideration in the logic.

So, my method signature on MailItem needs to look something like this:

public void ChangeStatus(bool mailSentSuccessfully)

The standard ISpecification interface does not cater for passing in an external value. Do I simply “bend” the standard implementation, or does this then break the “rules” of the definition of the pattern? If this is not the answer, what other pattern based options can I look into?

Answer 1

You can use the Specification pattern as it is simply by using a type for your candidate that includes the other object, i.e., build validation for a pair by extending ISpecification<Pair<MainType,ExternalType>>.

If you’re not working in a language that already supplies a Pair or Tuple type, you’ll of course have to create that as well to use this tactic.

Should that not work for you, it’s certainly ok to build your own variation on the pattern. They really aren’t rules of design, but guideposts.