Specification Pattern: Club Entry Rules

The Specification Pattern is a smart way to organise business rules as separate, reusable objects. Instead of scattering “if” statements everywhere, you write small classes for each rule and combine them as needed. This keeps your code clean and flexible, especially when requirements change.

When you have a list of checks—like who can enter an event, or which items to show in a shop—this pattern lets you build and mix these rules easily. You avoid duplication and make updates without risky changes to all your logic.

Real-Life Analogy: Club Entry Rules

Imagine a nightclub with a bouncer at the door. The club wants to allow only certain people inside, so they use several rules: Are you on the guest list? Are you over 21? Are you dressed properly? Each rule is checked one by one before you can go in.

The club can change the rules whenever they want. If there’s a special event, maybe only VIPs get in, or the dress code is stricter. The bouncer doesn’t need to know the details—he just follows the current set of rules, which can be updated anytime.

• The Bouncer → The code that checks if someone meets the rules (the specification evaluator)
• Guest List, Age, Dress Code → Separate rules (specification objects) that each check one thing
• Combining Rules → The club can use AND, OR, or NOT to make complex entry conditions (specification combinators)
• Changing Rules → The club can swap or add rules easily (you can update specifications in your code without rewriting everything)

Benefits of Specification Pattern

The Specification Pattern gives you these advantages:

• Reusable rules: Each rule is written once and can be used in many places.
• Flexible combinations: Combine rules with AND, OR, or NOT for any scenario.
• Easy to test: You can test each rule on its own.
• Cleaner code: Keeps your logic tidy and in one place, not scattered around.
• Adaptable: Change rules easily when business needs change.

What to Implement

These are the key building blocks of the Specification Pattern:

• Specification interface: A shared contract for all rules, like IsSatisfiedBy().
• Concrete specifications: Small classes that check one rule each, like AgeSpecification or GuestListSpecification.
• Combinators: Logic to combine specifications, such as And, Or, or Not.

How It Works in C#

Here is a simple example showing how the Specification Pattern works for club entry:

public interface ISpecification<T>
{
    bool IsSatisfiedBy(T candidate);
}

// Rule: Must be over 21
public class AgeSpecification : ISpecification<Person>
{
    public bool IsSatisfiedBy(Person candidate)
    {
        return candidate.Age >= 21;
    }
}

// Rule: Must be on the guest list
public class GuestListSpecification : ISpecification<Person>
{
    private readonly List<string> _guestList;
    public GuestListSpecification(List<string> guestList)
    {
        _guestList = guestList;
    }
    public bool IsSatisfiedBy(Person candidate)
    {
        return _guestList.Contains(candidate.Name);
    }
}

// Combine two specifications
public class AndSpecification<T> : ISpecification<T>
{
    private readonly ISpecification<T> _left;
    private readonly ISpecification<T> _right;
    public AndSpecification(ISpecification<T> left, ISpecification<T> right)
    {
        _left = left;
        _right = right;
    }
    public bool IsSatisfiedBy(T candidate)
    {
        return _left.IsSatisfiedBy(candidate) && _right.IsSatisfiedBy(candidate);
    }
}

// Usage:
var ageSpec = new AgeSpecification();
var guestSpec = new GuestListSpecification(guestList);
var entrySpec = new AndSpecification<Person>(ageSpec, guestSpec);

bool canEnter = entrySpec.IsSatisfiedBy(person);

When Should You Use It?

Use the Specification Pattern when your business rules are likely to change, need to be combined, or reused in different places. It is great for filtering collections, validating user input, or enforcing policies in domain-driven design.

When Not to Use It: If your rules are simple and do not change often, the pattern might be too much. For basic checks, a normal “if” is easier.

Where Is It Used in the Real World?

You'll see the Specification Pattern in enterprise software, domain-driven design, and apps that need flexible, reusable filters or rules.

• Validating complex forms with many rules
• Filtering lists or products by many conditions
• Checking security permissions and policies
• Workflow or rule engines
• Any place with rules that change often

Final Thoughts

The Specification Pattern helps you manage changing business rules without a mess. Like a club that changes its entry policy for every event, your software can stay neat, flexible, and ready for new requirements.