Specification Pattern
In this post I am going to show you what is a specification pattern and you will see how this pattern is so simple but yet so powerful and useful. This pattern is not part of the Gang of Four Pattern and was proposed by Martin Fowler and Eric Evans. The paper can be found here and I recommend to read it as the entire website is a great source of design patterns .
Anyway this is statement that Martin Fowler and Eric Evans stated in the paper.
Yes I agree that statement is too abstract and I need to show some code before we enter into the world of specification pattern.
public interface ISpecification { bool IsSatisfiedBy(object candidate); }
Aha so this is a simple interface which talks about how a candidate(entity) can be plugged in and the class which implements this interface will specify the satisfying condition for that candidate(entity).
This is again a good example of SOLID programming as we are seeing Interface, Separation of Concern and Single Responsibility Principle hmmm so far so good lets dig deeper.
Suppose you are building a loan approval application and the business rules states that a customer can apply for loan if a customer has good credit rating and have an equity more than $ 45,000.
Generally when we start writing a code in a hurry or not using good design principles we will be tempted either to put this business rule directly in our UI layer or in the Applicant entity. With out thinking that very soon this simple “if else” logic can grow complex and will have a code smell in which ever place we write, as there is no separation of concern and both the class(either UI or Entity ) will have more than one reason to change if had to change the business rules.
Now we know what the problem is and lets apply the pattern in practice to simplify the problem.So I will use the interface signature and use some generics to make it more sophisticated.
ISpecification.cs
public interface ISpecification<T> { bool IsSatisfiedBy(T candidate); }
As you can see using generics makes this interface much reusable and can be used for any class.Lets implement the specification class first
ApplicantLoanSpecification.cs
public class ApplicantLoanSpecification : ISpecification<Applicant> { public bool IsSatisfiedBy(Applicant candidate) { return (candidate.CreditRating == 10 && candidate.TotalEquity > 45000); } }
As you can see now we have a nice separation of concern and we have wrapped the condition logic(specification) into its own class.
Application.cs
public class Applicant { public Int32 Id { get; set; } public Int32 Age { get; set; } public Int32 CreditRating { get; set; } public decimal TotalEquity { get; set; } private readonly ApplicantLoanSpecification isQualitifiedForloan; public Applicant() { isQualitifiedForloan = new ApplicantLoanSpecification(); } public bool CanApplyForLoan() { return isQualitifiedForloan.IsSatisfiedBy(this); } }
This is how the class diagrams looks like.

As you can see the Applicant Entity just invokes the Loan Specification class and calls IsSatisfiedBy method now our Applicant class has just one responsibility and we are not coding the “if else” logic inside this class.
If in the future we need to change the business rule we will be changing the ApplicantLoanSpecification class and build the complex logic inside the class.Rest of the method signature (the contract) and the implementation remains the same and it also promotes less code smell, clean code and unit testing.
In the next post I’ll talk about Composition Pattern which will help us combine and chain specification pattern into a compound specification so that we can build complex business rules with out polluting the code and promote the practice of writing “Clean Code”.
Very nice and interesting, never thought of doing things this way and real good explanation. Waiting for the next part – Thnx
nice and clean like you said