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 Or(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 Or(ISpecification other)
{
return new OrSpecification(this, other);
}
public ISpecification Not()
{
return new NotSpecification(this);
}
}
public class AndSpecification : CompositeSpecification
{
private ISpecification One;
private ISpecification Other;
public AndSpecification(ISpecification x, ISpecification y)
{
One = x;
Other = y;
}
public override bool IsSatisfiedBy(object candidate)
{
return One.IsSatisfiedBy(candidate) && Other.IsSatisfiedBy(candidate);
}
}
public class OrSpecification : CompositeSpecification
{
private ISpecification One;
private ISpecification Other;
public OrSpecification(ISpecification x, ISpecification y)
{
One = x;
Other = y;
}
public override bool IsSatisfiedBy(object candidate)
{
return One.IsSatisfiedBy(candidate) || Other.IsSatisfiedBy(candidate);
}
}
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<TEntity>
{
bool IsSatisfiedBy(TEntity entity);
}
internal class AndSpecification<TEntity> : ISpecification<TEntity>
{
private readonly ISpecification<TEntity> _spec1;
private readonly ISpecification<TEntity> _spec2;
protected ISpecification<TEntity> Spec1
{
get
{
return _spec1;
}
}
protected ISpecification<TEntity> Spec2
{
get
{
return _spec2;
}
}
internal AndSpecification(ISpecification<TEntity> spec1, ISpecification<TEntity> spec2)
{
if (spec1 == null)
throw new ArgumentNullException("spec1");
if (spec2 == null)
throw new ArgumentNullException("spec2");
_spec1 = spec1;
_spec2 = spec2;
}
public bool IsSatisfiedBy(TEntity candidate)
{
return Spec1.IsSatisfiedBy(candidate) && Spec2.IsSatisfiedBy(candidate);
}
}
internal class OrSpecification<TEntity> : ISpecification<TEntity>
{
private readonly ISpecification<TEntity> _spec1;
private readonly ISpecification<TEntity> _spec2;
protected ISpecification<TEntity> Spec1
{
get
{
return _spec1;
}
}
protected ISpecification<TEntity> Spec2
{
get
{
return _spec2;
}
}
internal OrSpecification(ISpecification<TEntity> spec1, ISpecification<TEntity> spec2)
{
if (spec1 == null)
throw new ArgumentNullException("spec1");
if (spec2 == null)
throw new ArgumentNullException("spec2");
_spec1 = spec1;
_spec2 = spec2;
}
public bool IsSatisfiedBy(TEntity candidate)
{
return Spec1.IsSatisfiedBy(candidate) || Spec2.IsSatisfiedBy(candidate);
}
}
internal class NotSpecification<TEntity> : ISpecification<TEntity>
{
private readonly ISpecification<TEntity> _wrapped;
protected ISpecification<TEntity> Wrapped
{
get
{
return _wrapped;
}
}
internal NotSpecification(ISpecification<TEntity> spec)
{
if (spec == null)
{
throw new ArgumentNullException("spec");
}
_wrapped = spec;
}
public bool IsSatisfiedBy(TEntity candidate)
{
return !Wrapped.IsSatisfiedBy(candidate);
}
}
public static class ExtensionMethods
{
public static ISpecification<TEntity> And<TEntity>(this ISpecification<TEntity> spec1, ISpecification<TEntity> spec2)
{
return new AndSpecification<TEntity>(spec1, spec2);
}
public static ISpecification<TEntity> Or<TEntity>(this ISpecification<TEntity> spec1, ISpecification<TEntity> spec2)
{
return new OrSpecification<TEntity>(spec1, spec2);
}
public static ISpecification<TEntity> Not<TEntity>(this ISpecification<TEntity> spec)
{
return new NotSpecification<TEntity>(spec);
}
}
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.
OverDueSpecification OverDue = new OverDueSpecification();
NoticeSentSpecification NoticeSent = new NoticeSentSpecification();
InCollectionSpecification InCollection = new InCollectionSpecification();
// example of specification pattern logic chaining
ISpecification<Invoice> SendToCollection = OverDue.And(NoticeSent).And(InCollection.Not());
InvoiceCollection = Service.GetInvoices();
foreach (Invoice currentInvoice in InvoiceCollection) {
if (SendToCollection.IsSatisfiedBy(currentInvoice)) {
currentInvoice.SendToCollection();
}
}
Contrast without the Specification Pattern:
InvoiceCollection = Service.GetInvoices();
foreach (Invoice currentInvoice in InvoiceCollection) {
currentInvoice.SendToCollectionIfNecessary();
}
//.. in the Invoice partial class:
public bool ShouldSendToCollection { get { return currentInvoice.OverDue && currentInvoice.NoticeSent == false && currentInvoice.InCollection == false; }}
public void SendToCollectionIfNecessary()
{
//Guard condition - with each of those new properties
if (!ShouldSendToCollection) return;
this.SendToCollection();
}
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
| ||||||||||||||||||||||||||||||||||||||||