Modeling Business Objects as State Machines

For the simplest of business objects, state may not be worth considering. If you just have a simple content management system that allows administrative users to add articles and end users to view them, you probably don't have to worry about state. If, however you want to support rich, multi-stage editing workflows, looking at the objects as state machines with states that have attributes, actions, and state transitions can be useful. Similarly if you just have a simple login system, state isn't that crucial, but as your registration and authentication workflows become more complex, treating site users as state machines can also make sense.

Getting Started with State
Usually we think of a business object as being comprised of a collection of attributes and actions. A user may have a FirstName and LastName attribute as well as the ability to do things like login or subscribe to a newsletter. When you start to model objects in terms of state, both the data and the actions available for an object should be associated to one or more states, and there should be a method for each valid state transformation (the way an object gets from one state to another).

To take a simple example, if you have the concept of a SiteUser object that represents a given user of your website, they might have two states – Visitor and Registered. When they are visiting, the only available attribute might be their IP address and the only available methods might be login() and register(). The state transition from Visitor to Registered might be login() which would then provide access to attributes like FirstName, LastName and EmailAddress. A Registered SiteUser wouldn't be able to login() or register(), but they would be able to logout() which would then transition them back to the Visitor state until they chose to log in again.

Why Bother?
OK, so states provide a way for modeling the fact that the valid attributes and methods for on object vary over time based upon the state that the object is currently in. Why would this matter? Well, for complex business objects with lots of states, attributes and methods, it can sometimes be hard to keep track of which of the attributes and states for a given object can be used at different times. ?The idea of states can also be usefully applied to validation of data. Often the validation rules for an object depend on the state that it is trying to transition into. As a registered user, I might need to have a valid email address and password and that might be it, but if I want to be able to receive a printed catalog, I'm going to have to have a valid mailing address within a territory that the company is willing to deliver to.

States vs. Roles
For some use cases, the concept of roles may fit better than the concept of states. For example, if your permissions in a content management system are as an author, an editor and a superadmin, you're probably going to want to model that in terms of roles as a user can have multiple roles, but at any point in time an object can only have a single state. (Actually, an object could be associated to multiple orthogonal – independent – state machines, but for any given state machine they will only have one state at any point in time).

Generally roles are more useful for modeling a situation when on object can have multiple, simultaneous roles, and a state machine can make more sense when modeling an object thats attributes and methods can change over time but where at any given point in time the object will only be in a single state.

Do you use state machines to model the lifecycle of any of your business objects? If so, what objects and what are some of the example states? Anyone think state machines for modeling complex business objects are a bad idea? If so, why?

Also, how do you decide between associating (for instance) validations or attributes to a role, and associating them to a state?

Any thoughts appreciated.