Question

We often use simple enumerations to represent a state on our entities. The problem comes when we introduce behaviour that largely depends on the state, or where state transitions must adhere to certain business rules.

Take the following example (that uses an enumeration to represent state):

public class Vacancy {

    private VacancyState currentState;

    public void Approve() {
        if (CanBeApproved()) {
            currentState.Approve();
        }
    }

    public bool CanBeApproved() {
        return currentState == VacancyState.Unapproved
            || currentState == VacancyState.Removed
    }

    private enum VacancyState {
        Unapproved,
        Approved,
        Rejected,
        Completed,
        Removed
    }
}

You can see that this class will soon become quite verbose as we add methods for Reject, Complete, Remove etc.

Instead we can introduce the State pattern, which allows us to encapsulate each state as an object:

public abstract class VacancyState {

    protected Vacancy vacancy;

    public VacancyState(Vacancy vacancy) {
        this.vacancy = vacancy;
    }

    public abstract void Approve(); 
    // public abstract void Unapprove();
    // public abstract void Reject();
    // etc.

    public virtual bool CanApprove() {
        return false;
    }
}

public abstract class UnapprovedState : VacancyState {

    public UnapprovedState(vacancy) : base(vacancy) { }

    public override void Approve() {
        vacancy.State = new ApprovedState(vacancy);
    }

    public override bool CanApprove() {
        return true;
    }
}

This makes it easy to transition between states, perform logic based on the current state or add new states if we need to:

// transition state
vacancy.State.Approve();

// conditional
model.ShowRejectButton = vacancy.State.CanReject();

This encapsulation seems cleaner but given enough states, these too can become very verbose. I read Greg Young’s post on State Pattern Misuse which suggests using polymorphism instead (so I would have ApprovedVacancy, UnapprovedVacancy etc. classes), but can’t see how this will help me.

Should I delegate such state transitions to a domain service or is my use of the State pattern in this situation correct?

Answer 1

To answer your question, you shouldn’t delegate this to a domain service and your use of the State pattern is almost correct.

To elaborate, the responsibility for maintaining the state of an object belongs with that object, so relegating this to a domain service leads to anemic models. That isn’t to say that the responsibility of state modification can’t be delegated through the use of other patterns, but this should be transparent to the consumer of the object.

This leads me to your use of the State pattern. For the most part, you are using the pattern correctly. The one portion where you stray a bit is in your Law of Demeter violations. The consumer of your object shouldn’t reach into your object and call methods on it’s state (e.g. vacancy.State.CanReject()), but rather your object should be delegating this call to the State object (e.g. vacancy.CanReject() -> bool CanReject() { return _state.CanReject(); }). The consumer of your object shouldn’t have to know that you are even using the State pattern.

To comment on the article you’ve referenced, the State pattern relies upon polymorphism as it’s facilitating mechanism. The object encapsulating a State implementation is able to delegate a call to whichever implementation is currently assigned whether that be something that does nothing, throws an exception, or performs some action. Also, while it’s certainly possible to cause a Liskov Substitution Principle violation by using the State pattern (or any other pattern), this isn’t determined by the fact that the object may throw an exception or not, but by whether modifications to an object can be made in light of existing code (read this for further discussion).