Usually, we tend to represent objects status with boolean attributes. At first, this seems right and simple enough, but as the code base evolves and gets bigger, status become complex; so do the transitions between them.
Transition between status can be seen as behaviors or actions. Therefore, we find ourselves implementing rules to enforce behaviors and validating transitions; or even worse, not enforcing or validating anything at all.
Considering using a state machine to represent the status of an object may be ideal. As each state on the machine can represent an object status, the transitions between states can represent well defined actions or behaviors that can be performed between status.
This talk focuses on how to identify when booleans are not the right type to represent status, and how using a state machine may lead you to a better and cleaner design that can enforce conditions between status by simply relying on the definition of a state machine.