Question

I am thinking of using Specification pattern for validation purposes. The hard thing is how to tell the user why some Specification was not satisfied. What if the Specification.IsSatisfiedBy() will not only return a bool value, but also the reason of failure. It would look something like this:

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

where CheckResult is:

class CheckResult
{
  public bool IsSatisfied { get; }
  public string FailureReason { get; }
}

In Fowler & Evans work there is a concept of Partially Satisfied Specification whose purpose is to provide explanation what exactly was not satisfied. However in that document, it is implemented as additional method remainderUnsatisfiedBy which returns the Specification which was not accomplished by the Candidate.

So the question is: When using Specification for validation purposes, how to provide feedback to user that a given Specification was not satisfied? Is the solution I’ve presented above good?

Answer 1

Although you may use your Specifications classes for validation, I would suggest you keep them as separate concepts within your domain. You may find that you need to re-use the same underlying specifications but need to return different “Failure Reasons” depending on purpose and context. See this article for more details.

The author of the post referenced above has also kindly shared code to github and posted the code as NCommon. Review these areas in particular:

Specifications: https://github.com/riteshrao/ncommon/tree/v1.2/NCommon/src/Specifications

Validations: https://github.com/riteshrao/ncommon/tree/v1.2/NCommon/src/Rules (especially the classes for ValidationResult and ValidationError)