Home > Design Patterns, dotnet 4, SOLID > Specification Pattern

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.

The central idea of Specification is to separate the statement of how to match a candidate, from the candidate object that it is matched against. As well as its usefulness in selection, it is also valuable for validation and for building to order.

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.

Specification Pattern - Applicant Class Diagram

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”.

Advertisements
  1. Satish
    May 29, 2011 at 6:25 pm

    Very nice and interesting, never thought of doing things this way and real good explanation. Waiting for the next part – Thnx

  2. June 10, 2011 at 11:27 am

    nice and clean like you said

  1. June 5, 2011 at 10:07 am
  2. June 21, 2011 at 12:15 pm
  3. July 19, 2011 at 9:11 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: