Paul Lynch's Pages

This is genuine 1960s technology, but it moves forward into 1970s technology (OOP) very well.

Here’s the situation: you have a combination of two variables that need checking; for an example, perhaps an object has a status flag with a few different states, like failed, on hold, incomplete and registered – and you need to take different actions according to the state transition. Change of status from on hold to failed means set a processed date, and send failure email; change from incomplete to registered also sets the date and sends a different email, change from incomplete to on hold does nothing, etc. This is complex. You start coding it with if statements, perhaps, because you imagine that there are only one or two state transitions that need an action. Before you know it, you have 20 lines of code that you don’t understand.

The simple solution is to use a decision table. Grab a piece of paper (I have just coded one up from the back of an envelope that was already used for a different design problem), and lay down a grid. Set the actions for each state combination in the grid.

To implement this, I use a dictionary of dictionaries (most state tables are going to involve 2 variables, so this works). The hardest part is getting the Java code to correctly initialise the dictionaries. I use a string to represent the possible actions, space separated.


NSDictionary aDict = (NSDictionary)statusChangeDict.valueForKey(oldStatus);
String actionString = (String)aDict.valueForKey(company.status());
NSSet actions = new NSSet(actionString.split(" "));
if (actions.containsObject("D")) {
// action
}
if (actions.containsObject("E")) {
// action
}
if (actions.containsObject("S")) {
// action
}

Initialising the dictionaries:


protected String [] statusKeys = new String[] {
Company.OnHold, Company.Registered
};

This is cut down considerably from the real example, of course; for a 2 x 2 table, I wouldn’t use this technique, but would stick with the nested if’s. Note also that I am not using a switch statement, as the logic combinations for this, with fall throughs and break statements, over complicates the logic for simple understanding.

To make this a real object oriented programming example, we need to implement this as an object. I think I’d want a way to create decision tables as files that were simpler to create than the annoying Java object array technique, and probably use reflection to execute the actions (just name the method calls in the decision table file).

That is an exercise for later, for when spending the time creating this code is cost effective. Don’t do anything now if you don’t need to do it.