To help you do this, you'll often use some sort of state management library like Redux, React Context, or Recoil.

But in this article we are going to learn about global state management with the help of design patterns.

We will look at what design patterns are, and we'll focus on the singleton design pattern in particular. Finally we will look at an example of the singleton design pattern along with its advantages and disadvantages.

So without any further ado, let's get started.

Table of Contents

• Prerequisites

• What is a design pattern?

• What is the singleton design pattern?

• Pros and cons of the singleton design pattern

• Summary

Prerequisites

Before going through this article, I would highly recommend being familiar with the content in the following articles:

• What are classes in JavaScript?

• How to access DOM elements

• How object freeze works

What is a Design Pattern?

Design patterns provide conceptual solutions to common problems

A design pattern is a set of generalised instructions that provide a solution to commonly occurring problems in software design.

You can think about design patterns as a website that consists of multiple design templates you can use to build a site based on your specific needs.

So, now the question is – why is it important to know design patterns? Well, using design patterns has several benefits, such as:

• These patterns are proven – that is, these instructions are tried and tested, and they reflect the experience and insights of many developers.

• They're patterns that you can re-use easily.

• They are highly expressive.

Note that design patterns provide just a conceptual solution to a recurring problem in an optimised way. It does not provide a piece of code that you can use in your project.

So now that we know what design patterns are, let's dive into our very first design pattern.

What is the Singleton Design Pattern?

Singleton design pattern exposes a single instance that can be used by multiple components

Singleton is a design pattern that tells us that we can create only one instance of a class and that instance can be accessed globally.

This is one of the basic types of design pattern. It makes sure that the class acts as a single source of entry for all the consumer components that want to access this state. In other words, it provides a common entry point for using global state.

So a singleton class should be one which:

• Ensures that it creates only one instance of the class

• Provides a global access point to the state.

• Makes sure that the instance is only created the first time.

Example of the Singleton Design Pattern

To understand this concept in a better way, let's look at an example. This example is a simple React application that demonstrates how the global state value is used across the components, how it is being changed, and how the same value gets updated in all the components. Let's get started.

Before we start with the actual implementation, let's have a look at the folder structure:

.
├── index.html
├── package.json
└── src
    ├── componentA.js
    ├── componentB.js
    ├── globalStyles.js
    ├── index.js
    ├── styles.css
    └── utilities.js

Here are the details of each file:

• componentA.js is a consumer component that uses the singleton class to access the global state object and manipulate it.

• componentB.js is similar to above component, as it has to access the global state object and can manipulate it.

• globalStyles.js is a module that consists of the singleton class and exports the instance of this class.

• index.js manages global JS operations, that is JavaScript changes that are required for other DOM elements.

• styles.css manages the styling of the application. Consists of basic CSS.

• utilities.js is a module that exports some utility functions.

• index.html consists of HTML code for the components that are required in the project.

• package.json is a boilerplate configuration emitted by the npm init command.

Now that we know what each file does, we can start off by implementing them one by one.

But before we dive into this example, we need to understand the code flow. The aim of our example is to build a JavaScript application that demonstrates how the global style color is consumed by each of the components and how each component changes it.

Each component consists of a color-picker. When you change the global style color property via the color picker present inside each component, it automatically appears in other components and in the global state.

First, let's create a file: index.html. Then paste the below code into this file:

<!DOCTYPE html>
<html>
  <head>
    <title>Parcel Sandbox</title>
    <meta charset="UTF-8" />
    <link rel="stylesheet" href="./src/styles.css" />
  </head>

  <body>
    <div class="global-state">
      <h3>Global State</h3>
      <h4>Color</h4>
      <span id="selected-color"></span>
    </div>
    <div class="contents">
      <div class="component-a">
        <strong>Component A</strong>
        <div>Pick color</div>
        <span id="selected-color">black</span>
        <input type="color" id="color-picker-a" />
      </div>
      <div class="component-b">
        <strong>Component B</strong>
        <div>Pick color</div>
        <span id="selected-color">black</span>
        <input type="color" id="color-picker-b" />
      </div>
    </div>
    <script src="src/index.js"></script>
    <script src="src/componentA.js"></script>
    <script src="src/componentB.js"></script>
  </body>
</html>

Here at the top, we load our CSS via <link rel="stylesheet" href="./src/styles.css" />.

Then we have divided our application in two parts via two classes:

• .global-state: This will represent the HTML code for showcasing the current global state of the application.

• .contents: This will represent the HTML code that represents the two components.

Each of the components (component-a and component-b) has a color picker input element.

Both of these components have a span with class selected-color element that will help display the current value of global state variable color.

As you can see on a change of the color picker inside componentA, the following values are also changing:

• Value inside the .selected-color span element inside the componentB and Global state.

• Value of the color picker of componentA and componentB.

We will see later how all these values are changing. But for now it is important for us to understand that if we change the global state value from one component, then the singleton classes make sure that the instance value is updated and all the components that are consuming this instance get the same value since they are referring to the same instance.

Next, we create a file named globalStyles.js. Copy-paste the below code in it:

let instance;
let globalState = {
  color: ""
};

class StateUtility {
  constructor() {
    if (instance) {
      throw new Error("New instance cannot be created!!");
    }

    instance = this;
  }

  getPropertyByName(propertyName) {
    return globalState[propertyName];
  }

  setPropertyValue(propertyName, propertyValue) {
    globalState[propertyName] = propertyValue;
  }
}

let stateUtilityInstance = Object.freeze(new StateUtility());

export default stateUtilityInstance;

The above piece of code is a module that has a singleton class StateUtility and default exports the instance of the same class.

Let's dive deeper into the class StateUtility to understand how it resolves to become a singleton class:

• It consists of constructor and two class methods called getPropertyByName and setPropertyValue. Both of these class method are pretty self explanatory: one gets the property's value and the other sets its value.

• Next, we have the constructor function. It is a function that gets invoked whenever we create a new of object of this class.

• But here is a catch: for a class to be a singleton we need to make sure that it creates only one instance, and that's all.

• To make sure that this happens, we simply create a global variable called instance. We define it at the top of the module. This variable acts as a checker. We add a condition in the constructor function such that if instance variable has any value (that is, the object of the StateUtility class) then throw an error or else assign instance to the current class instance (the this object).

• In this example, we implemented the class StateUtility so that it can expose and alter the globalState variable.

• We make sure that we don't expose the globalState. We expose them using the class methods of StateUtility. In this way, we protect the global state from being altered directly.

• Finally, we create the instance of the class as follows: let stateUtilityInstance = Object.freeze(new StateUtility());.

• We have used Object.freeze so that no other class/component/module is able to modify the exposed stateUtilityInstance.

Then let's create a file called componentA.js inside the src folder. Copy-paste the below code in this file:

import {
    setAllSelectedColor
} from "./utilities";
import globalStyle from "./globalStyles";

// Get respective dom elements
const selectedColor = document.querySelectorAll("#selected-color");
const colorPickerA = document.getElementById("color-picker-a");
const colorPickerB = document.getElementById("color-picker-b");

// Event handler whenever a change event occurs
colorPickerA.onchange = (event) => {
    // set the color property of the global state with current color picker's value;
    globalStyle.setPropertyValue("color", event.target.value);
    const color = globalStyle.getPropertyByName("color");

    // A function thats sets the value of all the #selection-color dom elements;
    setValueOfSimilarElements(selectedColor, color);

    // make sure to set the component B's color picker value is set to color picker A;
    // this is done to make sure that both of the color picker have same value on change;
    colorPickerB.value = color;
};

Here is the breakdown of the above piece of code:

• The aim of this code is to make sure that we attach the onChange handler for the color picker that is present inside the component-a. In this case, componentA's color picker is identified by id: #color-picker-a.

• We need to make sure that this handler:

  1. Sets the value for the property color of the globalState.

  2. Fetches the same property again.

  3. Applies the same value to different areas of the DOM.

  4. Also makes sure that we set the other color picker's value to the global state.

Now, let's take a look at all these steps one-by-one:

• First, let's fetch all the required DOM elements.

• What we are planning here is to update all the color pickers and span elements with id #selected-color with the value of the current globalState property color whenever the on change event occurs.

• In case of componentA, once we change the color via the color picker we need to update the same value in 2 span elements (#selected-color) – that is, one span element of componentB and one span element present in the .global-state div container.

• We do this because we want to keep all the components in sync and demosntrate that the value of the global state remains the same across all the components.

• We then go ahead and update the color property of the global state using the StateUtility's class method setPropertyValue. We pass on to it event.target.value as this contains the current value present inside the #color-picker-a color picker input.

• Once the value is set, we fetch the same property again by using getPropertyByName. We do this to demonstrate that the property color of the global state has been updated and is ready to be used.

• Then, we use the setValueOfSimilarElements utility function to update all the elements that are having same class/id name with some value. In this case we update all the #selected-color elements with value color.

• Finally, we update the the value of the opposite color picker, that is componentB's color picker #color-picker-b.

We do the same thing for componentB. We create a file called componentB.js and update it with the following code:

import {
    setValueOfSimilarElements
} from "./utilities";
import globalStyle from "./globalStyles";

// Get respective dom elements
const selectedColor = document.querySelectorAll("#selected-color");
const colorPickerA = document.getElementById("color-picker-a");
const colorPickerB = document.getElementById("color-picker-b");

/**
 * Event handler whenever a change event occurs
 */
colorPickerB.onchange = (event) => {
    // set the color property of the global state with current color picker's value;
    globalStyle.setPropertyValue("color", event.target.value);

    const color = globalStyle.getPropertyByName("color");

    // A function thats sets the value of all the #selection-color dom elements
    setValueOfSimilarElements(selectedColor, color);

    // make sure to set the component A's color picker value is set to color picker B;
    // this is done to make sure that both of the color picker have same value on change;
    colorPickerA.value = color;
};

We do the same thing as of what we did inside the componentA file, but in this case we update the value of the color picker present inside componentA (that is, we update the value of element #color-picker-a).

Here is how our application will look like:

Here is the link to the code:

Pros and Cons of the Singleton Design Pattern

Here are some of the pros of using the Singleton design pattern:

• It makes sure that only a single instance of the class is created.

• We get a single access point to the instance that can be accessed globally.

Here are some cons of the Singleton design pattern:

• It violates the single responsibility principle. That is, it tries to solve two problems at the same time. It tries to solve the following problems: Ensure that a class will have only one instance, and assigning a global access point to the singleton class instance.

• It is difficult to write unit test cases for singleton classes. This is because the order of execution can change the value present in the global state, so the order of execution is important.

• While writing unit tests, there is a risk of another component or a module might be changing the global state value/instance. In such scenarios, it becomes difficult to debug the error.

Summary

The singleton design pattern can be useful in creating a global state that can be accessed by any component.

So to talk about singleton pattern in brief:

• It is a pattern that restricts the class to create only one instance.

• Singleton pattern can be considered the basics of global state management libraries such Redux or React Context.

• They can be accessed globally and acts as a single access point for accessing the global state.

That's all.

Thank you for reading!

Follow me on Twitter, GitHub, and LinkedIn.

What is a Design Pattern?

Design patterns are design level solutions for recurring problems that we software engineers come across often. It’s not code - I repeat, ❌CODE. It is like a description on how to tackle these problems and design a solution.

Using these patterns is considered good practice, as the design of the solution is quite tried and tested, resulting in higher readability of the final code. Design patterns are quite often created for and used by OOP Languages, like Java, in which most of the examples from here on will be written.

Types of design patterns

There are about 26 Patterns currently discovered (I hardly think I will do them all…).

These 26 can be classified into 3 types:

1. Creational: These patterns are designed for class instantiation. They can be either class-creation patterns or object-creational patterns.

2. Structural: These patterns are designed with regard to a class's structure and composition. The main goal of most of these patterns is to increase the functionality of the class(es) involved, without changing much of its composition.

3. Behavioral: These patterns are designed depending on how one class communicates with others.

In this post, we will go through one basic design pattern for each classified type.

Type 1: Creational - The Singleton Design Pattern

The Singleton Design Pattern is a Creational pattern, whose objective is to create only one instance of a class and to provide only one global access point to that object. One commonly used example of such a class in Java is Calendar, where you cannot make an instance of that class. It also uses its own getInstance()method to get the object to be used.

A class using the singleton design pattern will include,

Singleton Class Diagram

1. A private static variable, holding the only instance of the class.
2. A private constructor, so it cannot be instantiated anywhere else.
3. A public static method, to return the single instance of the class.

There are many different implementations of singleton design. Today, I’ll be going through the implementations of;

1. Eager Instantiation

2. Lazy Instantiation

3. Thread-safe Instantiation

Eager Beaver

public class EagerSingleton {
    // create an instance of the class.
    private static EagerSingleton instance = new EagerSingleton();

    // private constructor, so it cannot be instantiated outside this class.
    private EagerSingleton() {  }

    // get the only instance of the object created.
    public static EagerSingleton getInstance() {
        return instance;
    }
}

This type of instantiation happens during class loading, as the instantiation of the variable instance happens outside any method. This poses a hefty drawback if this class is not being used at all by the client application. The contingency plan, if this class is not being used, is the Lazy Instantiation.

Lazy Days

There isn’t much difference from the above implementation. The main differences are that the static variable is initially declared null, and is only instantiated within the getInstance() method if - and only if - the instance variable remains null at the time of the check.

public class LazySingleton {
    // initialize the instance as null.
    private static LazySingleton instance = null;

    // private constructor, so it cannot be instantiated outside this class.
    private LazySingleton() {  }

    // check if the instance is null, and if so, create the object.
    public static LazySingleton getInstance() {
        if (instance == null) {
            instance = new LazySingleton();
        }
        return instance;
    }
}

This fixes one problem, but another one still exists. What if two different clients access the Singleton class at the same time, right to the millisecond? Well, they will check if the instance is null at the same time, and will find it true, and so will create two instances of the class for each request by the two clients. To fix this, Thread Safe instantiation is to be implemented.

(Thread) Safety is Key

In Java, the keyword synchronized is used on methods or objects to implement thread safety, so that only one thread will access a particular resource at one time. The class instantiation is put within a synchronized block so that the method can only be accessed by one client at a given time.

public class ThreadSafeSingleton {
    // initialize the instance as null.
    private static ThreadSafeSingleton instance = null;

    // private constructor, so it cannot be instantiated outside this class.
    private ThreadSafeSingleton() {  }

    // check if the instance is null, within a synchronized block. If so, create the object
    public static ThreadSafeSingleton getInstance() {
        synchronized (ThreadSafeSingleton.class) {
            if (instance == null) {
                instance = new ThreadSafeSingleton();
            }
        }
        return instance;
    }
}

The overhead for the synchronized method is high, and reduces the performance of the whole operation.

For example, if the instance variable has already been instantiated, then each time any client accesses the getInstance() method, the synchronized method is run and the performance drops. This just happens in order to check if the instance variables’ value is null. If it finds that it is, it leaves the method.

To reduce this overhead, double locking is used. The check is used before the synchronized method as well, and if the value is null alone, does the synchronized method run.

// double locking is used to reduce the overhead of the synchronized method
public static ThreadSafeSingleton getInstanceDoubleLocking() {
    if (instance == null) {
        synchronized (ThreadSafeSingleton.class) {
            if (instance == null) {
                instance = new ThreadSafeSingleton();
            }
        }
    }
    return instance;
}

Now onto the next classification.

Type 2: Structural - The Decorator Design Pattern

I’m gonna give you a small scenario to give a better context to why and where you should use the Decorator Pattern.

Say you own a coffee shop, and like any newbie, you start out with just two types of plain coffee, the house blend and dark roast. In your billing system, there was one class for the different coffee blends, which inherits the beverage abstract class. People actually start to come by and have your wonderful (albeit bitter?) coffee. Then there are the coffee newbs that, God forbid, want sugar or milk. Such a travesty for coffee!! ??

Now you need to have those two add-ons as well, both to the menu and unfortunately on the billing system. Originally, your IT person will make a subclass for both coffees, one including sugar, the other milk. Then, since customers are always right, one says these dreaded words:

“Can I get a milk coffee, with sugar, please?”

???

There goes your billing system laughing in your face again. Well, back to the drawing board….

The IT person then adds milk coffee with sugar as another subclass to each parent coffee class. The rest of the month is smooth sailing, people lining up to have your coffee, you actually making money. ??

But wait, there’s more!

The world is against you once again. A competitor opens up across the street, with not just 4 types of coffee, but more than 10 add-ons as well!

You buy all those and more, to sell better coffee yourself, and just then remember that you forgot to update that dratted billing system. You quite possibly cannot make the infinite number of subclasses for any and all combinations of all the add-ons, with the new coffee blends too. Not to mention, the size of the final system.

Time to actually invest in a proper billing system. You find new IT personnel, who actually knows what they are doing and they say,

“Why, this will be so much easier and smaller if it used the decorator pattern.”

What on earth is that?

The decorator design pattern falls into the structural category, that deals with the actual structure of a class, whether is by inheritance, composition or both. The goal of this design is to modify an objects’ functionality at runtime. This is one of the many other design patterns that utilize abstract classes and interfaces with composition to get its desired result.

Let’s give Math a chance (shudder?) to bring this all into perspective.

Take 4 coffee blends and 10 add-ons. If we stuck to the generation of subclasses for each different combination of all the add-ons for one type of coffee. That’s:

(10–1)² = 9² = 81 subclasses

We subtract 1 from the 10, as you cannot combine one add-on with another of the same type, sugar with sugar sounds stupid. And that’s for just one coffee blend. Multiply that 81 by 4 and you get a whopping 324 different subclasses! Talk about all that coding…

But with the decorator pattern it will require only 16 classes in this scenario. Wanna bet?

Decorator Design Pattern Class diagram

Class diagram according to coffee shop scenario

If we map out our scenario according to the class diagram above, we get 4 classes for the 4 coffee blends, 10 for each add-on and 1 for the abstract component and 1 more for the abstract decorator. See! 16! Now hand over that $100.?? (jk, but it will not be refused if given… just saying)

As you can see from above, just as the concrete coffee blends are subclasses of the beverage abstract class, the AddOn abstract class also inherits its methods from it. The add-ons, that are its subclasses, in turn inherit any new methods to add functionality to the base object when needed.

Let’s get to coding, to see this pattern in use.

First to make the Abstract beverage class, that all the different coffee blends will inherit from:

public abstract class Beverage {
    private String description;

    public Beverage(String description) {
        super();
        this.description = description;
    }

    public String getDescription() {
        return description;
    }

    public abstract double cost();
}

Then to add both the concrete coffee blend classes.

public class HouseBlend extends Beverage {
    public HouseBlend() {
        super(“House blend”);
    }

    @Override
    public double cost() {
        return 250;
    }
}

public class DarkRoast extends Beverage {
    public DarkRoast() {
        super(“Dark roast”);
    }

    @Override
    public double cost() {
        return 300;
    }
}

The AddOn abstract class also inherits from the Beverage abstract class (more on this below).

public abstract class AddOn extends Beverage {
    protected Beverage beverage;

    public AddOn(String description, Beverage bev) {
        super(description);
        this.beverage = bev;
    }

    public abstract String getDescription();
}

And now the concrete implementations of this abstract class:

public class Sugar extends AddOn {
    public Sugar(Beverage bev) {
        super(“Sugar”, bev);
    }

    @Override
    public String getDescription() {
        return beverage.getDescription() + “ with Mocha”;
    }

    @Override
    public double cost() {
        return beverage.cost() + 50;
    }
}

public class Milk extends AddOn {
    public Milk(Beverage bev) {
        super(“Milk”, bev);
    }

    @Override
    public String getDescription() {
        return beverage.getDescription() + “ with Milk”;
    }

    @Override  public double cost() {
        return beverage.cost() + 100;
    }
}

As you can see above, we can pass any subclass of Beverage to any subclass of AddOn, and get the added cost as well as the updated description. And, since the AddOn class is essentially of type Beverage, we can pass an AddOn into another AddOn. This way, we can add any number of add-ons to a specific coffee blend.

Now to write some code to test this out.

public class CoffeeShop {
    public static void main(String[] args) {
        HouseBlend houseblend = new HouseBlend();
        System.out.println(houseblend.getDescription() + “: “ + houseblend.cost());

        Milk milkAddOn = new Milk(houseblend);
        System.out.println(milkAddOn.getDescription() + “: “ + milkAddOn.cost());

        Sugar sugarAddOn = new Sugar(milkAddOn);
        System.out.println(sugarAddOn.getDescription() + “: “ + sugarAddOn.cost());
    }
}

The final result is:

P.S. this is in Sri Lankan Rupees

It works! We were able to add more than one add-on to a coffee blend and successfully update its final cost and description, without the need to make infinite subclasses for each add-on combination for all coffee blends.

Finally, to the last category.

Type 3: Behavioral - The Command Design Pattern

A behavioral design pattern focuses on how classes and objects communicate with each other. The main focus of the command pattern is to inculcate a higher degree of loose coupling between involved parties (read: classes).

Uhhhh… What’s that?

Coupling is the way that two (or more) classes that interact with each other, well, interact. The ideal scenario when these classes interact is that they do not depend heavily on each other. That’s loose coupling. So, a better definition for loose coupling would be, classes that are interconnected, making the least use of each other.

The need for this pattern arose when requests needed to be sent without consciously knowing what you are asking for or who the receiver is.

In this pattern, the invoking class is decoupled from the class that actually performs an action. The invoker class only has the callable method execute, which runs the necessary command, when the client requests it.

Let’s take a basic real-world example, ordering a meal at a fancy restaurant. As the flow goes, you give your order (command) to the waiter (invoker), who then hands it over to the chef(receiver), so you can get food. Might sound simple… but a bit meh to code.

The idea is pretty simple, but the coding goes around the nose.

Command Design Pattern Class Diagram

The flow of operation on the technical side is, you make a concrete command, which implements the Command interface, asking the receiver to complete an action, and send the command to the invoker. The invoker is the person that knows when to give this command. The chef is the only one who knows what to do when given the specific command/order. So, when the execute method of the invoker is run, it, in turn, causes the command objects’ execute method to run on the receiver, thus completing necessary actions.

What we need to implement is;

1. An interface Command
2. A class Order that implements Command interface
3. A class Waiter (invoker)
4. A class Chef (receiver)

So, the coding goes like this:

Chef, the receiver

public class Chef {
    public void cookPasta() {
        System.out.println(“Chef is cooking Chicken Alfredo…”);
    }

    public void bakeCake() {
        System.out.println(“Chef is baking Chocolate Fudge Cake…”);
    }
}

Command, the interface

public interface Command {
    public abstract void execute();
}

Order, the concrete command

public class Order implements Command {
    private Chef chef;
    private String food;

    public Order(Chef chef, String food) {
        this.chef = chef;
        this.food = food;
    }

    @Override
    public void execute() {
        if (this.food.equals(“Pasta”)) {
            this.chef.cookPasta();
        } else {
            this.chef.bakeCake();
        }
    }
}

Waiter, the invoker

public class Waiter {
    private Order order;

    public Waiter(Order ord) {
        this.order = ord;
    }

    public void execute() {
        this.order.execute();
    }
}

You, the client

public class Client {
    public static void main(String[] args) {
        Chef chef = new Chef();

        Order order = new Order(chef, “Pasta”);
        Waiter waiter = new Waiter(order);
        waiter.execute();

        order = new Order(chef, “Cake”);
        waiter = new Waiter(order);
        waiter.execute();
    }
}

As you can see above, the Client makes an Order and sets the Receiver as the Chef. The Order is sent to the Waiter, who will know when to execute the Order (i.e. when to give the chef the order to cook). When the invoker is executed, the Orders’ execute method is run on the receiver (i.e. the chef is given the command to either cook pasta ? or bake cake?).

Final Client Output

Quick recap

In this post we went through:

1. What a design pattern really is,
2. The different types of design patterns and why they are different
3. One basic or common design pattern for each type

I hope this was helpful.

Find the code repo for the post, here.