Thinking in States

“Sorry, we’re super-duper, mega-out of milk.”

To a programmer, that’s an odd statement. You’re either out of milk or you’re not. There is no scale when it comes to being out of milk. Perhaps she was trying to tell me that they’d be out of milk for a week, but the outcome was the same — espresso day for me.

Consider a simple webshop that only accepts credit cards and does not invoice customers, with an class containing this method:

Reasonable, right? Well, even if the expression is nicely extracted into a method instead of copy’n’pasted everywhere, the expression shouldn’t exist at all. The fact that it does highlights a problem. Why? Because an order can’t be shipped before it’s paid. Thereby, hasShipped can’t be true unless is true, which makes part of the expression redundant. You may still want isComplete for clarity in the code, but then it should look like this:

• Paid: Can’t add or remove items. Can be shipped.

These states are important and you need to check that you’re in the expected state before doing operations, and that you only move to a legal state from where you are. In short, you have to protect your objects carefully, in the right places.

But how do you begin thinking in states? Extracting expressions to meaningful methods is a very good start, but it is just a start. The foundation is to understand state machines. I know you may have bad memories from CS class, but leave them behind. State machines are not particularly hard. Visualize them to make them simple to understand and easy to talk about. Test-drive your code to unravel valid and invalid states and transitions and to keep them correct. Study the State pattern. When you feel comfortable, read up on Design by Contract. It helps you ensure a valid state by validating incoming data and the object itself on entry and exit of each public method.

By Niclas Nilsson