Principles of Programming Part 2

Happy Clean Coding !!!

Anyway this is what the definition in the book is :-

In the past I have implemented various different implementation of this pattern but the common design pattern is that for a layer or suite of component with specialized behaviour we can abstract some behaviour or attribute to a base class so that we can remove some of the duplications.

For example say we are designing a business layer and we have set of business objects the purpose of this layer is to validate domain objects before it can be persisted in a data store. As we can see these business object will encapsulate this functionality from other layers, and its main functionality will be indicate whether the business object itself is valid or not and what the different violation it has from a business rules.

Well that’s a good starting point and things we have identified using our Object Oriented Analysis and Design ( OOAD ) are :-

• Business Rule (holds the rule definition)
• A base entity (to state whether the object is valid and what are the violations
• Business Object ( will implement the Entity Base )

Lets start writing some code :-

BusinessRule.cs

public class BusinessRule
{
   public string Property { get; set; }

   public string Rule { get; set; }

   public BusinessRule(string property, string rule)
   {
      Property = property;
      Rule = rule;
   }
}

EntityBase.cs

public abstract class EntityBase<T>
{
   private readonly List<BusinessRule> _brokenRules = new List<BusinessRule>();
   protected abstract void Validate();

   public IEnumerable<BusinessRule> GetBrokenRules()
   {
      _brokenRules.Clear();
      Validate();
      return _brokenRules;
   }

   protected void AddBrokenRule(BusinessRule businessRule)
   {
      _brokenRules.Add(businessRule);
   }
}

Lets implement a customer class which inherits from the EntityBase class.

Customer.cs

public class Customer : EntityBase<Int32>
{
   public Int32 Id { get; set; }
   public string FirstName { get; set; }
   public string LastName { get; set; }
   public DateTime DOB { get; set; }

   protected override void Validate()
   {
      if (string.IsNullOrEmpty(FirstName))
      {
         AddBrokenRule(new BusinessRule("FirstName","First name cannot be empty"));
      }

      if (string.IsNullOrEmpty(LastName))
      {
         AddBrokenRule(new BusinessRule("LastName", "Last name cannot be empty"));
      }

   }
}

And to complete the task lets write a unit test to check whether we get the desired result or not.

UnitTest.cs

[TestClass]
public class When_using_customer
{
   [TestMethod]
   public void Should_ab_able_to_validate_customer()
   {
      //Arrange
      var customer = new Customer();

      //Act
      var brokenRules = customer.GetBrokenRules().ToList();

      //Assert
      Assert.IsTrue(brokenRules.Count > 0);
   }
}

And now when we run our unit test we get the two broken rules for customer,also if you look at the EntityBase class closely we are using Template method pattern in the GetBrokenRules method which I blogged last year and can be found here.

Before we get into specifics of NServiceBus lets see what is an Enterprise Service bus and how does it fits into the realm of an enterprise. So the Wikipedia definition is

So here are some of the key features of NServiceBus :-

• It’s not a centralized broker like BizTalk or IBM Websphere Message Broker
• It’s not a Service Communication Framework like WCF.
• Build on top of MSMQ.
• Focuses on messaging and publish/subscribe model.
• It’s very robust and reliable
• There is no synchronous communication
• The Community Edition of NServiceBus is absolutely free and can handle up to 30 messages/sec which comes out to be around 2.59 million message a day on a decent quad-core server machine.
• The licensed version of NService is merely $2000 per license and can handle 100 messages/sec or 86.4 million messages.
• Highly extensible
• Written by the software simplest the great Udi Dahan.

Okay that’s was like the product overview but if you are like me, you might be itching to go ahead and use this stuff. So here is how you can jump into the NServiceBus wagon (oops the pun ).

• Go to http://nservicebus.com
• Click on “Download v2.5 SP1″
• Unzip the file and run RunMeFirst.bat as an admin
• Install or configure MSMQ
• Go to the samples folder and open the Full Duplex project

Just to get a feel of what the project structure looks so here it.

As you can see the project structure is self-explanatory, there is a client and a server and client is going to send a message and the server will take process the message and return it back to client.Lets run the project and see what happens.

and as you can see in the above figure that client and server are launched and ready to exchange messages. Lets hit enter in the Client console window and you will see the message gets send to the server with a Guid, which is received by the server and server sends back the message back to the client.

So till now nothing special but it’s time to go deeper and start tinkering with NServiceBus to understand some more. What I’ll now do is from the solution this time I’ll run only the client and not the server to mimic “a real life distributed application with reliable messaging” kind of scenario. So lets run the client project in isolation.

and we see that the client console windows gets launched and let hit enter to send a message to the service.So this is how it looks when we do that.

Now we will look how this message gets routed by NServiceBus. Lets open MSMQ and see where this message is routed and stored in MSMQ.

If you remember from the client console window that a message with a guid 3e8eeb98-0130-429a-862c-a56f5a02d95b but the message id in the server queue is something different and you must be wondering about this mismatch.

Lets open the message and see what’s in there.

So here in the message you can see the Data Id which matches the guid and this is how the server can correlated the incoming messaging and outgoing message to the client.

Now lets run the solution again and see how the NServiceBus will pick up the message process it and send it back to client and client will display the returned message from the server.

Viola !!! We see the NServiceBus picks up the message and processes it and return the message back to client and the client receives the processed message.If at this point you open the MSMQ and you will see that the message has been processed from the Server Queue and since the client has received the message the message disappears from the client queue. This is a good project to understand the core of NServiceBus and getting started with it.

One of thing I like about NServiceBus is the documentation is superb and all the sample projects are really good to understand. Hopefully I will able to bring more real-life & complex implementation of NServiceBus as I go my implementing in my current project.Till then …..

Enjoy !!!

If you haven’t read my previous post about the benefits of interface I recommend reading them and here are some of those posts.

• Interface design promotes better unit testing and TDD
• Building loosely coupled architecture
• Decorator Pattern
• Dependency Injection ( Getting Started with Castle Windsor )
• Specification Pattern
• Extension by Composition

In this post I am going to show another benefit of using interfaces and that is how easy it is to add additional behavior (decorators) without changing the code. With interfaces you are able to provide nice extensibility point and keeping our code SOLID ( yes it is the big ‘O‘ in SOLID) and as usual Dependency Injection plays a key role in accomplishing the task with minimal effort.

Let’s start with a simple interface like this one.

ICustomerRepository.cs

public interface ICustomerRepository
{
   List<Customer> GetCustomers();
}

And let’s write the CustomerRepository class which implements this interface.

public class CustomerRepository : ICustomerRepository
{
   public List<Customer> GetCustomers()
   {
      return new List<Customer>
                {
                   new Customer(1, "Joe", "Blogg"),
                   new Customer(2, "John", "Doe")
                };
   }
}

And this is our client code that calls the CustomerRepository class, it’s a standard example I have used in most of my posts depicting a real world example of business layer calling the repository layer.

CustomerBl.cs

public class CustomerBl : ICustomerBl
{
   private readonly ICustomerRepository _customerRepository;
   public CustomerBl(ICustomerRepository customerRepository)
   {
      _customerRepository = customerRepository;
   }

   public List<Customer> GetCustomers()
   {
      return _customerRepository.GetCustomers();
   }
}

I will add a simple class diagram for people who love to see the class diagram,as I personally favor class diagram over code.

As you can see nothing special, we are just using constructor injection in our CustomerBl so that through IoC I can decide which class will be injected into the CustomerBl as long as the class implements the ICustomerRepository interface (contract).

So far so good the code is running fine and it’s in production, your customer is happy and you feel good about it.

After some time the customer says that I want to do logging when this function is called and the first thing which comes to your mind is okay I will write a logging code in the CustomerRepository GetCustomers() method.

But wait lets put some thought into this. First as soon as you are modifying the CustomerRepository class you are breaking the Single Responsibility Principle as this class has now 2 reasons to change.

• If the GetCustomers() method logic changes
• If the logging mechanism changes

Lets think “does this logging really the CustomerRepository’s responsibility” and at the same time we don’t want to put the logging code into CustomerBl class as it’s not even its responsibility. And what about the logging it could change in the future.

So let’s abstract the logging responsibility into its own interface like this.

ILogger.cs

public interface ILogger
{
   void Log(string message);
}

And the class which implements this interface is

DebugLogger.cs

public class DebugLogger : ILogger
{
   public void Log(string message)
   {
      Debug.WriteLine(message);
   }
}

Here I have chosen a simple class which writes to the output window to keep the example as simple as possible and since we are implementing through interface we can easily change it into file based or database based logger using the Dependency Injection Principle.

Here is the interesting part as you can see from our ICustomerRepository interface that the CustomerBl class just care for this interface and has no knowledge of what the actual class does.

This gives us a good opportunity to implement a new class which has the same interface signature but does the logging and then calls our actual CustomerRepository class as is. With this philosophy nothing has changed and the new class would act as a proxy.

Hmmm let me show you the code and see if I can make more sense so I will create a new class called LogCustomerRepository which will implement the ICustomerRepository interface and will have dependency on it as well as on the ILogger interface.

LogCustomerRepository.cs

public class LogCustomerRepository : ICustomerRepository
{
   private readonly ICustomerRepository _customerRepository;
   private readonly ILogger _logger;

  public LogCustomerRepository(ICustomerRepository customerRepository,
         ILogger logger)
   {
      _customerRepository = customerRepository;
      _logger = logger;
   }

   public List<Customer> GetCustomers()
   {
      _logger.Log("Before the get customer method");
      var result = _customerRepository.GetCustomers();
      _logger.Log(string.Format("Total results found {0}", result.Count));
      return result;
   }
}

And an elaborated class diagram.

So as you can this class just decorates the CustomerRepository and it shouldn’t make any difference to the client code(CustomerBl) as both the class implement the same interface (contract).

Now only thing left is wire this up in our IoC and I am going to use Castle Windsor Installer to have a nice separation of the configuration from the actual container.

If you are not familiar with Castle Windsor installer class please read my previous post about it.

CustomerInstaller.cs

public class CustomerInstaller : IWindsorInstaller
{
   public void Install(IWindsorContainer container,
                       IConfigurationStore store)
   {
      container.Register(
         Component.For<ILogger>()
            .ImplementedBy<DebugLogger>(),

         Component.For<ICustomerRepository>()
            .ImplementedBy<CustomerRepository>(),

         Component.For<ICustomerRepository>()
            .ImplementedBy<LogCustomerRepository>()
            .Named("LogCustomerRepository"),

         Component.For<ICustomerBl>()
            .Named("CustomerBl")
            .ImplementedBy<CustomerBl>()
            .ServiceOverrides
            (
               ServiceOverride
                  .ForKey("customerRepository")
                  .Eq("LogCustomerRepository")
            )
      );
   }
}

This is the core of how registration and components works in Castle Windsor. The important thing to notice here is I am using named component registration as I want to make sure that when my CustomerBl class asks CastleWindsor to resolve for an implementation of type of ICustomerRepository it will return the LogCustomerRepository class instead of CustomerRepository and this way I am making sure that the decorators are invoked in the right order.

So in the ServiceOverrides method I am telling CastleWindsor that CustomerBl has a Dependency on ICustomerRepository and the name of the variable which is passed into the constructor is “customerRepository” and when you come across this variable then invoked the registered component which has been tagged as “LogCustomerRepository” rather than the default registered component CustomerRepository.

Although this syntax is very specific to Castle Windsor but the concept is quite uniform across all the IoC containers.

Let’s write a unit test to see how this all comes together.

UnitTest.cs

[TestClass]
public class When_using_CustomerBl
{
   private IWindsorContainer _container;
   [TestInitialize]
   public void Setup()
   {
      _container = new WindsorContainer();
      _container.Install(new CustomerInstaller());
   }

   [TestMethod]
   public void Should_be_able_to_get_customers()
   {
      var customerBl = _container
                        .Resolve<ICustomerBl>
                        ("CustomerBl");

      var result = customerBl.GetCustomers();
      Assert.IsTrue(result.Count > 0);
   }
}

And when I run the test it passes with the desired result and in the output window I do see the messages I expect.

As you can see from the Watch window that how these interfaces are resolved by Castle Windsor and how I am getting the correct type when I need it.

This way of decorating interfaces and creating decorators is a nice and easy pattern but it also gives us some insight into Aspect Oriented Programming as these decorators are merely cross cutting aspects.

For example we can easily create Logging,Security,Caching,Instrumentation etc decorators and Inject them with Castle Windsor.

We also unit tested some of these expression to see how the linq expression are built for And,Or, Not conditions and had that flexibility to apply them using lambada expression.

So in this post I will show you how we should write these specification like a rule specification to mimic a real life application.

As a good designed of any framework or API our main goal is to hide the inner complexity and workings from consuming code and try to expose them with easy interfaces and write some unit test to show how these API’s will be consumed.

Lets look at the employee class we created in our previous post and build some rule specifications.

Employee.cs

public class Employee
{
   public int Id { get; set; }
   public string FirstName { get; set; }
   public string LastName { get; set; }
   public virtual IList<Address> Address { get; set; }
}

And say the rule specifications for granting a leave are as follows :-

• If an employee has an address then he/she is preferred for taking a leave
• If an employee’s First Name starts with the letter ‘T’ then they are considered highly experienced
• And an employee satisfies the above 2 condition then only they can take a leave

I know these rules sounds really ridiculous but I just wanted to show the gravity of the rules, as I have always seen developers complaining that they couldn’t write a Clean Code or SOLID code because the business rules were way too complex and weird, or the client couldn’t make up their mind and kept on chopping and changing.

Yes I have faced the same situation before and in my opinion it is these confusing complex rules and inadequate unit test are the main culprit of bad design and failure of a system.Anyway that’s my personal opinion and let’s get back to writing these specification.

Employee Rule Specification

public class EmployeeRuleSpecification
   {
      public CompositionWithExpression<Employee> IsPreferred
      {
         get
         {
            return new CompositionWithExpression<Employee>
               (
                  e => e.Address.Count > 0
               );
         }
      }

      public CompositionWithExpression<Employee> IsExperienced
      {
         get
         {
            return new CompositionWithExpression<Employee>
               (
                  e => e.FirstName.StartsWith("T")
               );
         }
      }

      public CompositionWithExpression<Employee> And(
                     CompositionWithExpression<Employee> other)
      {
         return
            new CompositionWithExpression<Employee>
                                    (
                                       other.Predicate
                                    );
      }

      public ISpecificationWithExpression<Employee> PreferredAndExperienced
      {
         get
         {
            return (
                     this.IsPreferred.And(this.IsExperienced)
                   );
         }
      }
   }

[Pardon my indentation as I wanted to fit the long names and parameters with in the code box.]

So here what we have done is we have moved the responsibility of specifying the rules into its own class and which is good design practice (Single Responsibility Principle) and also the code looks very neat.

First If I am working on a huge project with the above code I don’t have to crawl though 1000 line to find out what this if else condition is trying to do.

Second if the rules changes or more rules need to be added I have to change only this class and that too because of the specification interface I am just adding a new specification and using composition compose a complex(compound) business rules.

Third important thing is that since I can do isolation testing on each expression as well as compound condition, I don’t have to go through 1000 lines of debugging to find out what condition is being invoked by the current state of the employee object. Otherwise we all have heard this thing “why it works in dev environment but fails in production” etc.

Lets plug this into our original Employee class by adding a new method CanTakeLeave.

public class Employee
   {
      public int Id { get; set; }
      public string FirstName { get; set; }
      public string LastName { get; set; }

      public virtual IList<Address> Address { get; set; }

      public bool CanTakeLeave()
      {
         var specification = new EmployeeRuleSpecification();
         return specification.IsExperienced
                             .And(specification.IsPreferred)
                             .IsSatisfiedBy(this);
      }
   }

As you can see the class still looks neat and compact and there is no ugly if/else/switch etc.Lets write a unit test to see how this method will be called and test what result are expected under what circumstances.

UnitTest.cs

[TestClass]
public class When_using_Employee_Rule_Specification
{
   [TestMethod]
   public void Should_be_able_to_take_leave()
   {
      var employee = BuildData.GetEmployeeWithAddress();
      var result = employee.CanTakeLeave();

      Assert.AreEqual(true, result);
   }
}

As you can see for this test to verify correctly I am calling the GetEmployeeWithAddress static on the static BuildData class which return an employee with his/her address and in this case my test passes with flying colors.

I hope this post will help you write complex specification and rules for a real life project as you can specify any number of these rules specification and compose them together to build complex rules.

Last but not the least is if you like you can this further and decouple the dependency of rule specification object and the business object i.e pass an interface to your business object, something like this.

public class Employee
{
   public int Id { get; set; }
   public string FirstName { get; set; }
   public string LastName { get; set; }
   public virtual IList<Address> Address { get; set; }

   public Employee(IEmployeeRuleSpecification employeeRuleSpecification)
   {

   }
}

and then you can use Dependency Injection to inject the rule specification which you might have boot strapped it your project.( May be I should leave that up to you guys )

Composition Pattern

Specification Pattern

In this post I am going to take both patterns and apply some Linq expression as I always try to refactoring code and improve coding style every time I get a chance.

In the Specification Pattern post we started with a simple interface ISpecification as following:

ISpecification.cs

public interface ISpecification<T>
{
    bool IsSatisfiedBy(T candidate);
    ISpecification<T> And(ISpecification<T> other);
    ISpecification<T> Or(ISpecification<T> other);
    ISpecification<T> Not();
}

And this interface is the core of the Composition Pattern so lets modify this interface so that we can use the Linq Expression provided by .NET.

ISpecificationWithExpression.cs

public interface ISpecificationWithExpression<T>
{
   Expression<Func<T, bool>> Predicate { get; }
   bool IsSatisfiedBy(T candidate);
   ISpecificationWithExpression<T> And(ISpecificationWithExpression<T> other);
   ISpecificationWithExpression<T> Or(ISpecificationWithExpression<T> other);
   ISpecificationWithExpression<T> Not();
}

The idea is that we are going to use Linq Expression and its internal expression building logic to chain our conditions and because we are using Expression<Func<T, bool>> we can specify our criteria (condition) as a lambada Expression.

Lets move on and first implement the interface to see how our code structure looks like, I always prefer it this way so that I can see the bigger picture without getting into implementation specifics.

public class CompositionWithExpression<T> : ISpecificationWithExpression<T>
{
   public Expression<Func<T, bool>> Predicate { get {  } }

   public bool IsSatisfiedBy(T candidate)
   {

   }

   public ISpecificationWithExpression<T> And(ISpecificationWithExpression<T> other)
   {

   }

   public ISpecificationWithExpression<T> Or(ISpecificationWithExpression<T> other)
   {

   }

   public ISpecificationWithExpression<T> Not()
   {

   }
}

So this gives us a base structure of our class and now all what we have to do is implement the And(), Or() and the Not() methods using Linq Expressions and its compositions.

CompositionWithExpression.cs

public class CompositionWithExpression<T> : ISpecificationWithExpression<T>
{
   private readonly Expression<Func<T, bool>> _predicate;

   public CompositionWithExpression(Expression<Func<T, bool>> predicate)
   {
      _predicate = predicate;
   }

   public Expression<Func<T, bool>> Predicate
   {
      get { return _predicate; }
   }

   public bool IsSatisfiedBy(T entity)
   {
      return _predicate.Compile().Invoke(entity);
   }

   public ISpecificationWithExpression<T> And (ISpecificationWithExpression<T> other)
   {
      var otherInvoke = Expression.Invoke( other.Predicate,
                                           this._predicate.Parameters);

      var newExpression = Expression.MakeBinary(ExpressionType.AndAlso,
                                                _predicate.Body, otherInvoke);

      return
      new CompositionWithExpression<T>(Expression.Lambda<Func<T, bool>>
                                                   (newExpression,
                                                   _predicate.Parameters));
   }

   public ISpecificationWithExpression<T> Or(ISpecificationWithExpression<T> other)
   {
      var otherInvoke = Expression.Invoke(other.Predicate,
                                          this._predicate.Parameters);

      var newExpression = Expression.MakeBinary(ExpressionType.OrElse,
                                                _predicate.Body, otherInvoke);

      return
      new CompositionWithExpression<T>(Expression.Lambda<Func<T, bool>>
                                                   (newExpression,
                                                   _predicate.Parameters));
   }

   public ISpecificationWithExpression<T> Not()
   {
      var negateExpression = Expression.Lambda<Func<T, bool>>
                                          (Expression.Not(_predicate.Body),
                                           _predicate.Parameters);

      return new CompositionWithExpression<T>(negateExpression);
   }
}

So far what we have done is that we have combined Lambada Expression based on method operation like Or,And and Not.

Lets write some unit test and see how we can use lambada expression to specify the condition.

[TestClass]
public class When_using_Specification_With_Expression
{
   [TestMethod]
   public void Should_be_able_to_invoke_or_condition()
   {
      var employee = BuildData.GetEmployee;

      var specification = new CompositionWithExpression<Employee>
                                 (e => e.FirstName.StartsWith("T"));

      var anotherSpecification = new CompositionWithExpression<Employee>
                                             (e => e.Address.Count > 0);

      var newExpression = specification.Or(anotherSpecification);

      Assert.AreEqual(true, newExpression.IsSatisfiedBy(employee));
   }

   [TestMethod]
   public void Should_be_able_to_invoke_an_and_condition()
   {
      var employee = BuildData.GetEmployee;
      employee.Address = BuildData.GetAddress;

      var specification = new CompositionWithExpression<Employee>
                                 (e => e.FirstName.StartsWith("T"));

      var andSpecification = new CompositionWithExpression<Employee>
                                          (e => e.Address.Count > 0);

      var compositeSpecification = specification.And(andSpecification);
      Assert.AreEqual(true, compositeSpecification.IsSatisfiedBy(employee));
   }

   [TestMethod]
   public void Should_be_able_to_invoke_a_not_condition()
   {
      var employee = BuildData.GetEmployee;
      employee.Address = BuildData.GetAddress;

      var specification = new CompositionWithExpression<Employee>
                                 (e => e.FirstName.StartsWith("T"));

      var negateSpecification = specification.Not();
      Assert.AreEqual(false, negateSpecification.IsSatisfiedBy(employee));
   }

}

and this is how the employee class looks like

public class Employee
{
   public int Id { get; set; }
   public string FirstName { get; set; }
   public string LastName { get; set; }
   public virtual IList<Address> Address { get; set; }
}

As you can see by the virtue of the fact that the CompositionWithExpression takes a Expression<Func<T, bool>> as constructor parameter,I can pass a lambada expression to specify the condition and it’s so easy to understand.

I think this has been a very lengthy post in terms of code so I will break it up into another post where I will revisit creating different specification and chain them in our entity class the way we did it for Customer class in the Composition Pattern post.

First lets see the pattern statement

The reason why we choose composition is that the interface we define in our Specification looks like a Predicate i.e. it takes an object as argument and returns a Boolean so if we chain multiple specification together it should still return a Boolean i.e. multiple specification can be together to yield whether the compound condition is true or not.

Lets look at three possible ways to combine these condition :-

1. And Specification
2. Or Specification
3. Not Specification

And lets add the above three specification to our ISpecification interface we created in the Specification Pattern post.

public interface ISpecification<T>
{
    bool IsSatisfiedBy(T candidate);
    ISpecification<T> And(ISpecification<T> other);
    ISpecification<T> Or(ISpecification<T> other);
    ISpecification<T> Not();
}

Now you can see how we are composing things together, in the interface since all the other specification have the same signature and the same return type we can combine them together without breaking the contract(interface) and this is the core principle of Composite Pattern.

Lets write a class which will implement this interface and will help us compose specifications.

public abstract class CompositeSpecification<T> : ISpecification<T>
{
    public abstract bool IsSatisfiedBy(T candidate);

    public ISpecification<T> And(ISpecification<T> other)
    {
        return new AndSpecification<T>(this, other);
    }

    public ISpecification<T> Or(ISpecification<T> other)
    {
        return new OrSpecification<T>(this, other);
    }

    public ISpecification<T> Not()
    {
        return new NotSpecification<T>(this);
    }
}

The important thing is that since the class has been designed using Generics it can be applied to any class. Lets write code for each of these Condition Specification.

public class AndSpecification<T> : CompositeSpecification<T>
{
    private readonly ISpecification<T> left;
    private readonly ISpecification<T> right;

    public AndSpecification(ISpecification<T> left, ISpecification<T> right)
    {
        this.left = left;
        this.right = right;
    }

    public override bool IsSatisfiedBy(T candidate)
    {
        return left.IsSatisfiedBy(candidate) && right.IsSatisfiedBy(candidate);
    }
}

public class NotSpecification<T> : CompositeSpecification<T>
{
    private readonly ISpecification<T> other;

    public NotSpecification(ISpecification<T> other)
    {
        this.other = other;
    }

    public override bool IsSatisfiedBy(T candidate)
    {
        return !other.IsSatisfiedBy(candidate);
    }
}

public class OrSpecification<T> : CompositeSpecification<T>
{
    private readonly ISpecification<T> left;
    private readonly ISpecification<T> right;

    public OrSpecification(ISpecification<T> left, ISpecification<T> right)
    {
        this.left = left;
        this.right = right;
    }

    public override bool IsSatisfiedBy(T candidate)
    {
        return left.IsSatisfiedBy(candidate)
                  || right.IsSatisfiedBy(candidate);
    }
}

Lets visualize it in a class diagram and see all the code we have written so far.

Lets modify the ApplicationLoanSpecification class we created in the previous post to implement the CompositePattern class.

public class ApplicantLoanSpecification : CompositeSpecification<Applicant>
{
    public override bool IsSatisfiedBy(Applicant candidate)
    {
        return (candidate.CreditRating == 10 && candidate.TotalEquity > 45000);
    }
}

So far nothing has change drastically and now we will start creating some more specifications.

public class SalarySpecification : CompositeSpecification<Applicant>
{
    public override bool IsSatisfiedBy(Applicant candidate)
    {
        return (candidate.Salary > 100000);
    }
}

public class AgeSpecification : CompositeSpecification<Applicant>
{
    public override bool IsSatisfiedBy(Applicant candidate)
    {
        return (candidate.Age < 80);
    }
}

So here I just created some fictitious conditions to create a real life complex business rules, the important thing is that because of using the pattern each of my class are very small and very specific(pardon the pun). And it’s another good example of Single Responsibility principle.Lets put it all together in our Applicant class and see how the method chaining looks like.

public class Applicant
{
    public Int32 Id { get; set; }
    public Int32 Age { get; set; }
    public Int32 CreditRating { get; set; }
    public decimal TotalEquity { get; set; }
    public decimal Salary { get; set; }

    private readonly ISpecification<Applicant> isQualifiedForLoan;
    private readonly ISpecification<Applicant> salaryIsQualified;
    private readonly ISpecification<Applicant> ageIsLessthanEighty;

    public Applicant()
    {
        isQualifiedForLoan = new ApplicantLoanSpecification();
        salaryIsQualified = new SalarySpecification();
        ageIsLessthanEighty = new AgeSpecification();

    }
    public bool CanApplyForLoan()
    {
        var canApplyForLoan = isQualifiedForLoan.
                               And(salaryIsQualified.
                               And(ageIsLessthanEighty));

        return canApplyForLoan.IsSatisfiedBy(this);
    }
}

You can see how our applicant business object encapsulates the business logic but have a nice separation of concern with these specifications. Also you might have noticed that the method chaining is done through a fluent interface.The whole condition can be read as “Is Qualified for Loan and Salary is qualitified and Age is less than Eighty”.

Lets see how we will invoke our applicant class from outside and I know I should have written a unit test, but hey its a blog post and sometimes even I feel lazy .

static void Main(string[] args)
{
    var applicant = new Applicant()
                        {
                            Salary = 150000,
                            Age = 25,
                            CreditRating = 10,
                            TotalEquity = 55000
                        };

    Console.WriteLine("Can apply for loan:{0}",applicant.CanApplyForLoan());
    Console.ReadKey();
}

And when we run the program we get a true result as this applicant instance does satisfy all the conditions.I encourage you to get a full depth of this concept and try experiment with other Specification like the “Or” and “Not”. If you have any problem understanding or chaining other specification please feel to get in touch with me.

Last but not the least if you are designing any layered application/core framework for your application,it will be great if you can provide a nice fluent interface to other programmers.

Here is a quick video demo and it is planned to be shipped around June.

For more information please visit the Microsoft Research website.

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

Anyway without going into much details that why this feature didn’t make it to its first release, lets focus on how we can execute stored procedure which maps to a table.

I recommend you read my previous post which explains the idea behind POCOContextScript class, so we will add 2 more constants which has the DML for the stored procedures.

POCOContextScript.cs

public static class POCOContextScript
{
   public const string CreateProcGetAllProducts
      = @"create procedure [dbo].[GetAllProducts]
            as
            begin
                set nocount on;
                select * from product
            end";

   public const string CreateProcGetProductById
      = @"create procedure [dbo].[GetByProductId]
             @productid int
           as
           begin
               set nocount on;
               select * from product p
               where p.id = @productid
           end";
}

Nothing special just 2 sql procedure statement to get all products and get a specific product by id. Now we will follow the way we used in the previous post we can hook this into a class which implements the IDatabaseInitializer interface and lets run a unit test to see how we can invoke them.

GetAllProduct

[TestMethod]
public void Should_be_able_to_execute_sql()
{
   var context = new POCOContext();
   var result = context.Product.SqlQuery("GetAllProducts").ToList();
   Assert.IsTrue(result.Count > 0);
}

GetByProductId

[TestMethod]
public void Should_be_able_to_get_product_by_id()
{
   var context = new POCOContext();
   var parameter = new SqlParameter
   {
      DbType = DbType.Int32,
      ParameterName = "ProductId",
      Value = 1
   };

   var result = context.Product.SqlQuery
                                ("GetByProductId @ProductId",
                                   parameter
                                ).FirstOrDefault();

   Assert.AreEqual(1, result.Id);
}

That’s it for now and I hope the ADO.Net team is working on this feature for the next release and along with bulk copy and other features the next version will be even better.