Is this a good alternative to state pattern?

Question

I was trying to use the state pattern in a DDD aggregate, but I was thinking in the following alternative.

In sumary, the state pattern controls what actions can be done in each state. This makes to create one class of each possible state and implement it. So if I want to add a new state I have to modify the code.

I was thinking in this alternative. To have a table States in my database, with one column for each possible action the tell if it is possible or not. Something like that:

State(ID, Name, CanDoAction1, CanDoAction2..., CanGoToSate1, canGoToState2,...)

So in my domain, the order aggregate only needs to have the information of the state, and to see if it is possible to do or not according of the state.

This avoid the use of inheritance to implement the state pattern, and the code would be simplier.

But I don't know if this a good option or not.

Another motivation is that using state pattern, I am not able to configure EF to use state as value object because I am not able to configure the state as owned entity, but this would be another history for another post.

Thanks.

Answer 1

Indeed, the state pattern is not the only way to manage states. Some are much simpler that your proposed approach. The state pattern adds a level of complexity but covers most of the cases. The approach to recommend always depends on the problem you’re trying to solve with the states.

Your solution addresses very well the case where:

• the state defines what behavior is allowed in a predefined catalogue of behaviors.
• behaviors are relatively decoupled from the state, e.g. they can be encapsulated in a command.
• complex behaviors of a state can be decomposed into a combination of several more elementary behaviors where the order is not dependent of the state.

It does not deal well with a situation where the behavior is slightly different for each state (would require lots of redundancies in the code), or when several families of objects share the same state logic but with very different behaviors (adding a new family would require to modify the codebase to add new behaviors in the predefined table, potentially breaking OCP).

Answer 2

So in my domain, the order aggregate only needs to have the information of the state, and to see if it is possible to do or not according of the state.

Well that works fine so long as there is no code associated with deciding which transition to take. That is, each State (and its outgoing state transition decisions) must be themselves stateless.

That is, you're not really implementing the State pattern as originally written, but a Finite-state Machine (FSM). Specifically, you're just putting the State/Event table in a database. You still also need to add a way to associate actions with your state transitions.

Note that you can absolutely write a GoF State without using inheritance - virtual dispatch is an implementation detail. The details depend on the language you're using though, which you haven't specified.