Strategy State

Friends Don’t Let Friends Use String States

by on July 8, 2013 10:40 am

Many of my coworkers have covered exciting new technologies and frameworks to aid your programming expertise. But at this time I think it is important to reach back and cover an important programming basic. Throughout my programming career one of the most common anti-patterns I have seen is the “String State.” It has appeared in some form or another in every project I have worked on.

Simply put, the String State anti-pattern is the use of a Java String to represent the state of an object.

Sure, string representations of states are important. You want the code to be readable, you want a readable value in the database for reports, and you want a user-readable representation of the state to present on your interface. All of these are good things and you should have some string representation of your state — but don’t let string be the entire implementation of your state.

Take for example this simplified version of a shopping cart:

package stringstate;

public class Item {
	private String name;
	private int price;
	public String getName() {
		return name;
	}
	public void setName(String name) {
		this.name = name;
	}
	public int getPrice() {
		return price;
	}
	public void setPrice(int price) {
		this.price = price;
	}
}

package stringstate;

public interface OrderState {
	public static String OPEN = "Open";
	public static String CLOSED = "Closed";
}

package stringstate;

import java.util.ArrayList;
import java.util.List;

public class Order implements OrderState {
	private List items = new ArrayList();
	private String orderState;

	public List getItems() {
		return items;
	}

	protected  void setItems(List items) {
		this.items = items;
	}

	public String getOrderState() {
		return orderState;
	}

	public void setOrderState(String orderState) {
		this.orderState = orderState;
	}

	public void addItem(Item anItem){
		getItems().add(anItem);
	}

}

In this example the state is used for no business logic. In this case a string state would not be harmful. However no project is this simple. Even if a state starts out as display/store only, you will eventually use it for business logic. Trust me – if the state of an object is important enough to store, then eventually you will have to make decisions with it.

So now your oversimplified shopping cart needs to prevent people from adding items if it is closed. Easy: add a new method and modify addItem.

public void addItem(Item anItem){
		if (canModify()){
			getItems().add(anItem);
		} else {
			throw new IllegalStateException("Cannot add items to a closed order");
		}
	}

	public boolean canModify(){
		return getOrderState().equals(OPEN);
	}

So far not that bad.

Why am I so down on string states you ask? Because now you want to add 2 new states New and Finalized, as well as give the user the option to reopen a non-finalized order. Sure, a new method, a modification to canModify, a check on setOrderState and we are on our way.

But wait, now the user wants 2 Finalized states: Shipped and Canceled. Just a few more tweaks, right?

Now your order code is riddled with “if statements” having to do with states:

package stringstate;

import java.util.ArrayList;
import java.util.List;

public class Order implements OrderState {
	private List items = new ArrayList();
	private String orderState;

	public List getItems() {
		return items;
	}

	protected  void setItems(List items) {
		this.items = items;
	}

	public String getOrderState() {
		return orderState;
	}

	public void setOrderState(String orderState) {
		if (!isFinalized()){
			this.orderState = orderState;
		}
	}

	public void addItem(Item anItem){
		if (canModify()){
			getItems().add(anItem);
		} else {
			throw new IllegalStateException("Cannot add items to a closed order");
		}
	}

	public boolean canModify(){
		return getOrderState().equals(OPEN);
	}

	public void reOpen(){
		if (!isFinalized()){
			setOrderState(OPEN);
		}
	}

	public boolean isFinalized(){
		return getOrderState().equals(SHIPPED) || getOrderState().equals(CANCELED);
	}
}

Oops, we forgot to add the new state to canModify().

Now take the example of a Strategy State in which all the state logic is delegated to an object smarter than a string.

The first benefit is to make all the logic in the order about the order, and not about the order state. The next benefit is anytime you add a new decision based on state, you can implement it abstractly to force implementation in all the states or to provide a default implementation.

Order:

package strategystate;

import java.util.ArrayList;
import java.util.List;

public class Order {
	private List items = new ArrayList();
	private OrderState orderState;

	public List getItems() {
		return items;
	}

	protected  void setItems(List items) {
		this.items = items;
	}

	public OrderState getOrderState() {
		return orderState;
	}

	public void setOrderState(OrderState orderState) {
		if (!getOrderState().isFinalized()){
			this.orderState = orderState;
		}
	}

	public void addItem(Item anItem){
		if (getOrderState().canModify()){
			getItems().add(anItem);
		} else {
			throw new IllegalStateException("Cannot add items to a closed order");
		}
	}

	public void reOpen(){
		if (!getOrderState().isFinalized()){
			setOrderState(OrderState.OPEN);
		}
	}

}

public enum OrderState {
	NEW("New",true,false),
	OPEN("Open",true,false),
	CLOSED("Closed",false,false),
	SHIPPED("Shipped",false,true),
	CANCELED("Canceled",false,true);

	protected String name;
	protected boolean finalized;
	protected boolean modify;

	private OrderState(String name, boolean canModify, boolean isFinalized){
		this.name = name;
		this.finalized= isFinalized;
		this.modify = canModify;
	}
	public boolean canModify(){
		return modify;
	}
	public boolean isFinalized(){
		return finalized;
	}
	public String getName(){
		return name;
	}
}

The more states and more logic you have based on state, the more benefit you have from a strategy state. The Strategy State keeps your main business objects free from growing “if statements” based on lists of states. Plus, you get to keep all the conveniences of the string.

The difference may be small in this example but as the complexity of the domain grows, so does the benefit of the strategy state. Plus, what project have you ever worked on where the complexity didn’t grow? My recommendation is to always start with a strategy state. The overhead is small and you will thank yourself when the project complexity grows.

— Brad Mongar, asktheteam@keyholesoftware.com

  • Share:

5 Responses to “Friends Don’t Let Friends Use String States”

  1. Phil says:

    In .NET, they handle enums a little differently (they’re basically labels for ints instead of strings), and I quit using them long ago in favor of the Strategy State for exactly these reasons.

    In fact, I tend to use Strategy State for anything I might normally use an enum for (including a list of the United States – equivocation ftw!) unless I am 99.9% sure I will never need those items to be anything other than a single value representation.

    • Brad Mongar says:

      Phil, good contrast with .NET. I am mostly a Java guy so I was unaware of the differences in the enum implementation. I do like that the Java enum allows for full class implementations of individual enum instances. They can even each be a different classes not just individually initialized instances of the same class. It makes the Java enum a great way to implement Strategy States. I look forward to learning more about .NET and C# and a bit disappointed to hear the enums aren’t as powerful.

  2. Frisian says:

    Good example, so I have finally a bookmark for those developers, who spill enum comparisons all over the place :-)
    Given your example, I would even go further: First, add dedicated methods open(), close(), cancel() and ship() alike reOpen(). setOrderState() should be private and be called by the aforementioned methods.
    Second, the enum can be extended to be a finite state machine, so the Order class just calls something like getOrderState().next(newState). With an interface one can even switch the FSM for different kind of orders. The BabyState example in http://cyrille.martraire.com/2012/08/java-enums-you-have-grace-elegance-and-power-and-this-is-what-i-love/ is a good demonstration.
    Two minor things: The condition in line 23 of the final example should be negated and there should be an initial orderState value.

    • Brad Mongar says:

      Frisian, thanks for your feedback. I fixed the not condition – thanks for pointing that out. You are right that hiding the set state and having business operations set the state would be a better implementation. I was just trying to keep the example simple. :)

Leave a Reply

Things Twitter is Talking About
  • Did you know today is Clean Your Virtual Desktop Day? It really is: https://t.co/TCRpWgTmxg Celebrate by organizing your desktop files.
    October 20, 2014 at 4:50 PM
  • Don't miss the newest post from @bricemciver: Make Me a Promise - http://t.co/obK811q48q #JavaScript
    October 20, 2014 at 10:43 AM
  • RT @DZone: #Docker 1.3 Releases with Security, Signed Images, and Process Injection by @bendzone #devops http://t.co/uytIwFPgO6
    October 17, 2014 at 10:04 AM
  • If you have 15+ years #Java exp, you don't expect to be puzzled debugging a null pointer exception. See an exception: http://t.co/m2iDgNEleK
    October 17, 2014 at 9:51 AM
  • Many on our team attended the #Royals victory last night & @cdesalvo even got a selfie with the Gov. Go #KansasCity! http://t.co/N1Psooe2CE
    October 16, 2014 at 3:39 PM
  • Interesting ExplainLikeI'm5 talk: Why do companies develop iOS first when Android holds 70% of the 'Smart' Market? http://t.co/fxgjIBmqBi
    October 16, 2014 at 12:26 PM
  • We're looking for a top-notch #Java developer to join our team. Learn more about our company culture & the role - http://t.co/0fKsFmN0Ql
    October 16, 2014 at 9:08 AM
  • Want to learn to create custom #Java annotations & process them using the Reflection API? @jhackett01's tutorials - http://t.co/mf1F3eIDY3
    October 15, 2014 at 11:43 AM
  • Happy Ada Lovelace Day! It's a celebration of the achievements of women in STEM - if there's a woman in tech that you admire, tell her today
    October 15, 2014 at 9:13 AM
  • .@fpmoles We absolutely agree - thanks for reading!
    October 15, 2014 at 8:13 AM
  • With 15 yrs exp, @bmongar didn't expect surprise when debugging a null pointer exception. Why it puzzled him - http://t.co/m2iDgNEleK #Java
    October 14, 2014 at 11:20 AM
  • #Royals fans with tickets to tonight's canceled game, here's what you need to know - http://t.co/EErHht3zoN
    October 13, 2014 at 4:23 PM
  • RT @UzilitySoftware: Watch as Wayne explains to the boss, Marvin, what an agile board is about. #scrumalliance #scrum http://t.co/5MzB1bNw…
    October 13, 2014 at 12:01 PM
  • Getting started with #MongoDB? (Flexible #NoSQL for Humongous Data) Here's a free cheat sheet from the folks @Dzone - http://t.co/oBMvICzfcL
    October 13, 2014 at 11:10 AM
  • Brad Mongar's newest post is live on the Keyhole blog - #Java and the Sweet Science http://t.co/m2iDgNEleK
    October 13, 2014 at 8:59 AM
  • RT @housecor: If users have share links to your web app like this: "Go to here. Then click here. Then here." You're doing it wrong. #de
    October 10, 2014 at 2:18 PM
  • CSS is 20 years old today! Happy birthday, #CSS - web design would not be the same without you. http://t.co/8tEMoUjorI
    October 10, 2014 at 9:55 AM
  • Expansion update: remodel, electrical & mudding done; painting in process; carpet to go. We can't wait for our bigger team rooms!
    October 10, 2014 at 8:42 AM
  • Want an easy way to get all of our development blog posts sent straight into your email? Try this new IFTTT Recipe: http://t.co/b9RgUqGU4v
    October 9, 2014 at 10:55 AM
  • #JavaScript & #Java handle secure random number generation differently. Here's how they stack up - http://t.co/QENl4kGVIs #cryptography
    October 8, 2014 at 12:27 PM
Keyhole Software
8900 State Line Road, Suite 455
Leawood, KS 66206
ph: 877-521-7769
© 2014 Keyhole Software, LLC. All rights reserved.