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.

Specification Pattern in UML

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# 6.0 with generics

    public interface ISpecification<T>
    {
        bool IsSatisfiedBy(T candidate);
        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 candidate) => AsExpression().Compile()(candidate);
    }

    public abstract class CompositeSpecification<T> : ISpecification<T>
    {
        public abstract bool IsSatisfiedBy(T candidate);
        public ISpecification<T> And(ISpecification<T> other) => new AndSpecification<T>(this, other);
        public ISpecification<T> AndNot(ISpecification<T> other) => new AndNotSpecification<T>(this, other);
        public ISpecification<T> Or(ISpecification<T> other) => new OrSpecification<T>(this, other);
        public ISpecification<T> OrNot(ISpecification<T> other) => new OrNotSpecification<T>(this, other);
        public ISpecification<T> Not() => new NotSpecification<T>(this);
    }

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

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

        public override bool IsSatisfiedBy(T candidate) => left.IsSatisfiedBy(candidate) && right.IsSatisfiedBy(candidate);
    }

    public class AndNotSpecification<T> : CompositeSpecification<T>
    {
        ISpecification<T> left;
        ISpecification<T> right;

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

        public override bool IsSatisfiedBy(T candidate) => left.IsSatisfiedBy(candidate) && !right.IsSatisfiedBy(candidate);
    }

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

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

        public override bool IsSatisfiedBy(T candidate) => left.IsSatisfiedBy(candidate) || right.IsSatisfiedBy(candidate);
    }
    public class OrNotSpecification<T> : CompositeSpecification<T>
    {
        ISpecification<T> left;
        ISpecification<T> right;

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

        public override bool IsSatisfiedBy(T candidate) => left.IsSatisfiedBy(candidate) || !right.IsSatisfiedBy(candidate);
    }

    public class NotSpecification<T> : CompositeSpecification<T>
    {
        ISpecification<T> other;
        public NotSpecification(ISpecification<T> other) => this.other = other;
        public override bool IsSatisfiedBy(T candidate) => !other.IsSatisfiedBy(candidate);
    }

Python

from abc import abstractmethod
from dataclasses import dataclass
from typing import Any

class BaseSpecification:
    @abstractmethod
    def is_satisfied_by(self, candidate: Any) -> bool:
        raise NotImplementedError()

    def and_(self, other: "BaseSpecification") -> "AndSpecification":
        return AndSpecification(self, other)

    def or_(self, other: "BaseSpecification") -> "OrSpecification":
        return OrSpecification(self, other)

    def not_(self) -> "NotSpecification":
        return NotSpecification(self)

@dataclass(frozen=True)
class AndSpecification(BaseSpecification):
    first: BaseSpecification
    second: BaseSpecification

    def is_satisfied_by(self, candidate: Any) -> bool:
        return self.first.is_satisfied_by(candidate) and self.second.is_satisfied_by(candidate)

@dataclass(frozen=True)
class OrSpecification(BaseSpecification):
    first: BaseSpecification
    second: BaseSpecification

    def is_satisfied_by(self, candidate: Any) -> bool:
        return self.first.is_satisfied_by(candidate) or self.second.is_satisfied_by(candidate)

@dataclass(frozen=True)
class NotSpecification(BaseSpecification):
    subject: BaseSpecification

    def is_satisfied_by(self, candidate: Any) -> bool:
        return not self.subject.is_satisfied_by(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 (var invoice in InvoiceCollection) invoice.SendToCollectionIfNecessary();

// Invoice methods:
public void SendToCollectionIfNecessary()
{
    if (ShouldSendToCollection()) SendToCollection();
}

private bool ShouldSendToCollection() => 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).

gollark: We can assume that the AI runs faster than humans because people will only run training for a few months at most before they get bored and stop.

gollark: Legal action was maybe also bad.

gollark: I do think the DALL-E Mini name was kind of bad.

gollark: I could automatically do business with an associate though. Probably not fast enough to trademark that much, but it should be possible to do short word sequences.

gollark: Can anyone stop me from trademarking all possible byte sequences (up to some length) preemptively?

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
The Specification Pattern in TypeScript and JavaScript by Thiago Delgado Pinto
specification pattern in flash actionscript 3 by Rolf Vreijdenberger

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.

Software design patterns
Creational	Abstract factory Builder Dependency injection Factory method Lazy initialization Multiton Object pool Prototype RAII Singleton
Structural	Adapter Bridge Composite Decorator Delegation Facade Flyweight Front controller Marker interface Module Proxy Twin
Behavioral	Blackboard Chain of responsibility Command Interpreter Iterator Mediator Memento Null object Observer Servant Specification State Strategy Template method Visitor
Functional	Monoid Functor Applicative Monad Comonad Free monad HOF Currying Function composition Closure Generator
Concurrency	Active object Actor Balking Barrier Binding properties Coroutine Compute kernel Double-checked locking Event-based asynchronous Fiber Futex Futures and promises Guarded suspension Immutable object Join Lock Messaging Monitor Nuclear Proactor Reactor Read write lock Scheduler STM Thread pool Thread-local storage
Architectural	ADR Active record Broker Client–server CBD DAO DTO DDD ECB ECS EDA Front controller Identity map Interceptor Implicit invocation Inversion of control Model 2 MOM Microservices MVA MVC MVP MVVM Monolithic Multitier Naked objects ORB P2P Publish–subscribe PAC REST SOA Service locator Specification
Cloud Distributed	Ambassador Anti-Corruption Layer Bulkhead Cache-Aside Circuit Breaker CQRS Compensating Transaction Competing Consumers Compute Resource Consolidation Event Sourcing External Configuration Store Federated Identity Gatekeeper Index Table Leader Election MapReduce Materialized View Pipes Filters Priority Queue Publisher-Subscriber Queue-Based Load Leveling Retry Scheduler Agent Supervisor Sharding Sidecar Strangler Throttling Valet Key
Other	Business delegate Composite entity Intercepting filter Lazy loading Mangler Mock object Type tunnel Method chaining
Books	Design Patterns Enterprise Integration Patterns Code Complete POSA
People	Christopher Alexander Erich Gamma Ralph Johnson John Vlissides Grady Booch Kent Beck Ward Cunningham Martin Fowler Robert Martin Jim Coplien Douglas Schmidt Linda Rising
Communities	The Hillside Group The Portland Pattern Repository