Applying the State Design Pattern to Real-World Scenarios

In my previous article, I wrote about the Singleton Design Pattern and a possible real-world application for it. In this article, I will do the same for the State Pattern. In addition, I will use the example from my previous post to implement the states in my state machine. But I cannot start showing examples unless I help you understand first the basic concept of this topic.

The first question I must answer is what is the State Design Pattern.

What is the State Design Pattern?

The State Design Pattern is one of the original Design Patterns proposed by the Gang of Four (GoF). The pattern falls under the Behavioral classification or category. This means that the purpose of this design is to come up with a scheme to control the behavior of objects. Specifically, it is used to model behavior of objects that must behave like a state machine. A state machine is a device that can be in one of a set number of stable conditions depending on its previous condition and on the values of its inputs, or stimuli.

When to use State Pattern

To understand this definition, consider a turnstile. A typical (simple) turnstile is a machine that can be in one of three states at any given time: locked, unlocked, and rotating. The transition from one state to another is predefined and can only occur if a proper stimulus or input is applied. For example, to transition from locked to unlocked, the turnstile must receive a coin. Assuming that the turnstile doesn't have some sort of time out feature, it will remain on that state until a proper stimulus or input is received. From this state, a push is the expected input to transition from unlocked to rotating. The turnstile will remain in the rotating state until one revolution is achieved and then will return to the locked state; where it will remain until a valid input (coin) is received and so on...

From the example above, you can see that a state machine has:

  1. A predefined (finite) number of states
  2. Predefined condition(s) to trigger a transition
  3. Specific path(s) to the next state - and maybe to a previous state
State machines are definitely procedural. That said, your code doesn't have to be. But you can use object-oriented constructs to achieve that same behavior and that is what the State Design Pattern does. I have used the state pattern many times in my career. From all of the real-world applications I have developed in the past using this pattern, the one that makes the most sense is using it to control the behavior of a wizard.

Part III of this blog will be the conclusion. In that blog, I will show some UML diagrams as well as some code examples on how to create a simple wizard using Singleton and State Design Patterns.

Stay tuned!

Comments

Post a Comment

Popular posts from this blog

Combining State and Singleton Patterns to Create a State-Machine

Image
In my previous two posts, I discussed real-world applications for the Singleton and State design patterns. In this article, I am going to illustrate how to combine both of these patterns to create a simple wizard. Simple State Design Pattern Implementation In a typical implementation of the design pattern, State is either an interface or abstract class, with each state of the state machine being Singleton classes. My example is going to be slightly different. I will implement the state machine using a state interface and Java enums to implement the Singleton. Using an enum is the recommended way to implement a Singleton in Java. First, let's come up with a simple state interface State.java public interface State { void goNext(Context input); void goPrevious(Context input); } Now that we have an interface defined, we can derive as many states as we need. For this example, three states should be sufficient to demonstrate the wizard's functionality. Jav
Read more

Exception Handling: File CRUD Operations Example

Image
Introduction to Exception Handling This is a supplement to my previous blog Creating Custom Exception Classes in Java . I recommend you read that one first and then read this one. Java provides many Exception (and Error) Handling classes. Both of these categories implement the Throwable interface. Although it is not imperative that you develop your own custom exception classes, it is often a good idea to do so; particularly when dealing with large systems. The main reason to create custom exception classes is to quickly identify which custom class is being affected or causing these custom exceptions. For example, referencing a null object and trying to use it will result in a NullPointerException . However, in your code, there could be literally hundreds or even thousands of statements which could result in such exception. Designing your Custom Exception Class Suppose that you are designing a class that will serve as a message receiver. For simplicity,
Read more

The Beauty of the Null Object Pattern

Image
Before we start... Let me start by saying this: NEVER dismiss an idea without giving it any consideration. That was the mistake I made when I first encountered an article about this design pattern many years ago. I was thrown off by the name and without even attempting to find out what this design pattern was all about, I moved on to other things. That was a huge mistake and I am not afraid to admit it. I urge you not to make that mistake. And if you have already, never make that mistake again. Trust me, you will thank me later. For now, let me tell you my story and attempt to explain when to use it along with a simple example on how to implement this pattern. The Null Object Pattern By definition, the main purpose of this pattern is to have an Object-Oriented alternative to the absence of objects by creating objects that display "do nothing" behavior. That sounds like a mouthful. In simplest terms, it is meant to provide a mechanism to replace null references w
Read more