Modern State Pattern using Enums and Functional Interfaces

It’s offen the case that the behaviour of an object should change depending on the objects state. Consider a ShoppingBasket object. You can add articles to your basket as long the order isn’t submitted. But once it’s submitted you typically don’t want to be able to change that order anymore. So, there are two states in such a shopping basket object: READONLY and UPDATEABLE . Here is the ShoppingBasket class.

In such a class, you can add articles and maybe you can perform an order. Once you’ve performed an order, the client of such an object would still be able to change that order object which should not be possible. To prevent clients from updating the order, that was already submitted, we want to change the behaviour of the ShoppingBasket . It should not be possible to add articles or change the orderNo field, once the order is submitted. What’s an intelligent object-oriented modern Java solution to such a problem? What I usually do in such cases, I use an enum to implement a GoF state pattern. Here is such an enum :

My UpdateState enum takes an Runnable object as constructor argument. You can use more complicated functional interfaces to suit specific needs, the sky is your limit in terms of complexity here. But for now, its an ordinary Runnable interface. The UpdateState enum has exactly two states: UPDATEABLE and READONLY . The UPDATEABLE enum value does validate to true, always, the READONLY enum value always evaluates to false, which results in an InvalidStateException (using Apache Commons Lang Validate class). The UpdateState enum has a method called set() which takes an argument, and returns exactly that given argument. But before returning the argument, the set() method runs the state dependend Runnable action. Now, why all that hassle?

The ShoppingBasket now has a state field of enum type UpdateState . That state field defaults to UPDATEABLE cause when you create the ShoppingBasket it’s always updateable, meaning: the order wasn’t submitted yet. When you fire the order through the order() method, the state changes to READONLY . Since the state changed to read-only, the ShoppingBasket will change its behaviour, specifically when clients try to access the class fields. Let’s look at the setOrderNo() method for instance. The setOrder() method does not assign the order number directly to the orderNo field anymore, instead it calls the UpdateState enums set() method, which returns that given value you want to set. That return value is assigned to your orderNo field. The set() method of the UpdateState enum always checks whether updates are allowed. So when your ShoppingBaskets state is UPDATEABLE, the set() method will succeed, but when its READONLY then the set() method of that state will result in IllegalStateException. This was exactly what we’ve wanted to achieve in the beginning, make that object read-only, if the order is submitted.

Notice that you can make such a state pattern implementation as complex as required. It’s a very elegant, short option to drive your objects behaviour by objects state. And it saves you a lot if-else typing non-object-oriented logic in all the accessor methods. Consider classes that have 20 fields, you don’t want to check state each time in all the methods. That would clearly clutter up your class code. Using the demonstrated state pattern, you save lines of code and your place looks quite tidy. Change the functional interface used in the UpdateState enum and you’ll realize the great potential of state dependend behaviour that can be implemented with very little lines of code.