Figure 2: A UML example of violating the Expert and Polymorphism patterns

Translating the UML design from Figure 2 would generate a Java structure like the one shown in Figure 3.

Figure 3: A Java example, violating Expert and Polymorphism

The GoF pattern catalog offers a possible solution for our design challenge. The pattern is called State.

First we verify that the pattern meets our needs and read the intend, application, and consequences sections of the pattern. Because the pattern says that it "Allows an object to alter its behavior when its internal state changes. The object will appear to change its class [GoF]," we go ahead and apply this pattern to our problem.

One of the benefits of applying the State pattern is that it can resolve the if-statement situation difficulty shown in Figure 3 by isolating the various states. The UML state-machine notation helps us depict and investigate the various states. Initially our timesheet was fairly simple and we isolated two states out of our existing structure, Approved and Not Approved.

Figure 4: UML state-machine diagram for timesheet (two states)

Instead of asking the object which value is nested in an attribute (in our case is Approved) and make a decision based on that (which violate the principle of polymorphism) we instead tell the object what to do and simply send the message to it and let the Timesheet object deal with the event. What we would like to design is some way to send a message, as shown below, where ts is a Timesheet object.

Figure 5: New responsibility assignment for timesheet (Java)

After we isolate the various states, remove the if-construct from the Timesheet object, and assign the three responsibilities (enter, approve and reject), we then want to apply the State pattern to our solution. Using the RSA pattern explorer we navigate to the State pattern, which shows us the participating classes in the pattern.

 

Figure 6: State pattern and participating classes within the RSA pattern explorer

In order to get an overview of the structure of the State pattern, the pattern explorer provides us the following layout:

Figure 7: State pattern structure within the RSA pattern explorer

The cookie-cutter solution for the State pattern needs to be adjusted to accommodate our application's specific needs. After dragging the pattern from the pattern explorer directly into our workspace, we can assign the participating classes from our application-specific class model. The following diagram contains now the Timsheet as a context object, the Java interface ITimesheetState for the State and both concrete states from our timesheet application (Approved and Not Approved).