Specification pattern
In computer programming, the specification pattern is a particular software design pattern, whereby business rules can be recombined by chaining the business rules together using boolean logic. The pattern is frequently used in the context of domain-driven design.
A specification pattern outlines a business rule that is combinable with other business rules. In this pattern, a unit of business logic inherits its functionality from the abstract aggregate Composite Specification class. The Composite Specification class has one function called IsSatisfiedBy that returns a boolean value. After instantiation, the specification is "chained" with other specifications, making new specifications easily maintainable, yet highly customizable business logic. Furthermore, upon instantiation the business logic may, through method invocation or inversion of control, have its state altered in order to become a delegate of other classes such as a persistence repository.
Code examples
C#
public interface ISpecification
{
bool IsSatisfiedBy(object candidate);
ISpecification And(ISpecification other);
ISpecification AndNot(ISpecification other);
ISpecification Or(ISpecification other);
ISpecification OrNot(ISpecification other);
ISpecification Not();
}
public abstract class CompositeSpecification : ISpecification
{
public abstract bool IsSatisfiedBy(object candidate);
public ISpecification And(ISpecification other)
{
return new AndSpecification(this, other);
}
public ISpecification AndNot(ISpecification other)
{
return new AndNotSpecification(this, other);
}
public ISpecification Or(ISpecification other)
{
return new OrSpecification(this, other);
}
public ISpecification OrNot(ISpecification other)
{
return new OrNotSpecification(this, other);
}
public ISpecification Not()
{
return new NotSpecification(this);
}
}
public class AndSpecification : CompositeSpecification
{
private ISpecification leftCondition;
private ISpecification rightCondition;
public AndSpecification(ISpecification left, ISpecification right)
{
leftCondition = left;
rightCondition = right;
}
public override bool IsSatisfiedBy(object candidate)
{
return leftCondition.IsSatisfiedBy(candidate) && rightCondition.IsSatisfiedBy(candidate);
}
}
public class AndNotSpecification : CompositeSpecification
{
private ISpecification leftCondition;
private ISpecification rightCondition;
public AndNotSpecification(ISpecification left, ISpecification right)
{
leftCondition = left;
rightCondition = right;
}
public override bool IsSatisfiedBy(object candidate)
{
return leftCondition.IsSatisfiedBy(candidate) && rightCondition.IsSatisfiedBy(candidate) != true;
}
}
public class OrSpecification : CompositeSpecification
{
private ISpecification leftCondition;
private ISpecification rightCondition;
public OrSpecification(ISpecification left, ISpecification right)
{
leftCondition = left;
rightCondition = right;
}
public override bool IsSatisfiedBy(object candidate)
{
return leftCondition.IsSatisfiedBy(candidate) || rightCondition.IsSatisfiedBy(candidate);
}
}
public class OrNotSpecification : CompositeSpecification
{
private ISpecification leftCondition;
private ISpecification rightCondition;
public OrNotSpecification(ISpecification left, ISpecification right)
{
leftCondition = left;
rightCondition = right;
}
public override bool IsSatisfiedBy(object candidate)
{
return leftCondition.IsSatisfiedBy(candidate) || rightCondition.IsSatisfiedBy(candidate) != true;
}
}
public class NotSpecification : CompositeSpecification
{
private ISpecification Wrapped;
public NotSpecification(ISpecification x)
{
Wrapped = x;
}
public override bool IsSatisfiedBy(object candidate)
{
return !Wrapped.IsSatisfiedBy(candidate);
}
}
C# 3.0, simplified with generics and extension methods
public interface ISpecification<T>
{
bool IsSatisfiedBy(T entity);
ISpecification<T> And(ISpecification<T> other);
ISpecification<T> AndNot(ISpecification<T> other);
ISpecification<T> Or(ISpecification<T> other);
ISpecification<T> OrNot(ISpecification<T> other);
ISpecification<T> Not();
}
public abstract class LinqSpecification<T> : CompositeSpecification<T>
{
public abstract Expression<Func<T, bool>> AsExpression();
public override bool IsSatisfiedBy(T entity)
{
Func<T, bool> predicate = AsExpression().Compile();
return predicate(entity);
}
}
public abstract class CompositeSpecification<T> : ISpecification<T>
{
public abstract bool IsSatisfiedBy(T entity);
public ISpecification<T> And(ISpecification<T> other)
{
return new AndSpecification<T>(this, other);
}
public ISpecification<T> AndNot(ISpecification<T> other)
{
return new AndNotSpecification<T>(this, other);
}
public ISpecification<T> Or(ISpecification<T> other)
{
return new OrSpecification<T>(this, other);
}
public ISpecification<T> OrNot(ISpecification<T> other)
{
return new OrNotSpecification<T>(this, other);
}
public ISpecification<T> Not()
{
return new NotSpecification<T>(this);
}
}
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 AndNotSpecification<T> : CompositeSpecification<T>
{
private readonly ISpecification<T> left;
private readonly ISpecification<T> right;
public AndNotSpecification(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) != true;
}
}
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);
}
}
public class OrNotSpecification<T> : CompositeSpecification<T>
{
private readonly ISpecification<T> left;
private readonly ISpecification<T> right;
public OrNotSpecification(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) != true;
}
}
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);
}
}
Example of use
In the following example, we are retrieving invoices and sending them to a collection agency if
- they are overdue,
- notices have been sent, and
- they are not already with the collection agency.
This example is meant to show the end result of how the logic is 'chained' together.
This usage example assumes a previously defined OverdueSpecification class that is satisfied when an invoice's due date is 30 days or older, a NoticeSentSpecification class that is satisfied when three notices have been sent to the customer, and an InCollectionSpecification class that is satisfied when an invoice has already been sent to the collection agency. The implementation of these classes isn't important here.
Using these three specifications, we created a new specification called SendToCollection which will be satisfied when an invoice is overdue, when notices have been sent to the customer, and are not already with the collection agency.
var OverDue = new OverDueSpecification();
var NoticeSent = new NoticeSentSpecification();
var InCollection = new InCollectionSpecification();
// example of specification pattern logic chaining
var SendToCollection = OverDue.And(NoticeSent).And(InCollection.Not());
var InvoiceCollection = Service.GetInvoices();
foreach (var currentInvoice in InvoiceCollection) {
if (SendToCollection.IsSatisfiedBy(currentInvoice)) {
currentInvoice.SendToCollection();
}
}
Criticisms
The Specification Pattern could be considered a software Anti-Pattern:
- Cargo Cult Programming - There lacks a well-defined purpose for this pattern, and there's no guide when to implement it or not. Also, see Law of the instrument.
- Inner-platform effect - And() function which directly replicate && in C#. Also, Not() and potentially more. Also, see Reinventing the square wheel.
- Spaghetti/Lasagna Code - Separate classes for each part of the specification fragments what could be a cohesive object. In the example above, OverDue is an extra layer between the Logic for SendToCollection and the OverDueSpecification implementation.
Most natural programming languages can accommodate domain-driven design with the core Object Oriented concepts.
Alternative example, without the Specification Pattern:
var InvoiceCollection = Service.GetInvoices();
foreach (Invoice invoice in InvoiceCollection) {
invoice.SendToCollectionIfNecessary();
}
// Invoice methods:
public void SendToCollectionIfNecessary()
{
if (ShouldSendToCollection())
{
SendToCollection();
}
}
private bool ShouldSendToCollection()
{
return currentInvoice.OverDue
&& currentInvoice.NoticeSent
&& !currentInvoice.InCollection;
}
This alternative uses foundation concepts of Get-Only Properties, Condition-Logic, and Functions. The key alternative here is Get-Only Properties, which are well-named to maintain the Domain-Driven language, and enable the continued use of the natural && operator, instead of the Specification Pattern's And() function. Furthermore, the creation of a well-named function SendToCollectionIfNecessary is potentially more useful and descriptive, than the previous example (which could also be contained in such a function, except not directly on the object apparently).
References
- Evans, Eric (2004). Domain Driven Design. Addison-Wesley. p. 224.
External links
- Specifications by Eric Evans and Martin Fowler
- The Specification Pattern: A Primer by Matt Berther
- The Specification Pattern: A Four Part Introduction using VB.Net by Richard Dalton
- The Specification Pattern in PHP by Moshe Brevda
- Happyr Doctrine Specification in PHP by Happyr
- The Specification Pattern in Swift by Simon Strandgaard
- specification pattern in flash actionscript 3 by Rolf Vreijdenberger