The Singleton Pattern

The Singleton Pattern provides only one instance of a class. It is useful when we want to centralize a certain behavior such as querying the database or writing in files.

First, we want to make sure we create only one instance. The basic pattern looks this way:

public class Singleton {

  private static final Singleton INSTANCE = new Singleton();

  private Singleton() {} // not possible to call the constructor from outside the class

  public static Singleton getInstance() {
    return INSTANCE;
  }
}

There are problems with this though. It is possible to create more than one instance by using:

  1. the Reflection API
  2. Serialization. The JVM does not care about the private constructor when serializing/deserializing. To fix this, we just need to add the readResolve method:
protected Object readResolve() {
  return INSTANCE; // return the existing instance instead of creating a new one.
}

For Serializable classes, the readResolve method let us replace/resolve the object read from the stream before it is returned to the caller. By implementing the readResolve method, a class can directly control the types and instances of its own instances being deserialized.

Second, we want to guarantee a lazy initialization. We want to make sure we only create the instance when we need it. It can be as simple as:

publics static Singleton getInstance() {
  if (instance != null) {
    instance = new Singleton();
  }
  return instance
}

Third, we want to guarantee thread safety. In the previous case, if there are multi-threads and they access the method at the same time, they may create their two instances (one for each thread). It is possible to create an inner static Singleton using a nested class:

class Singleton {

  private Singleton() {}

  // Nested class 
  private static class Builder {

     private static final Singleton INSTANCE = new Singleton();

     public Singleton getInstance() {
       return Builder.INSTANCE;
     }
  }
}

It is also possible to use enum instead of class. Using an Enum solves the issue with the Reflection API, but it does not allow you to persist an internal state through serialization despite the fact that all the enum are serializable. For example:

public enum Singleton {
  INSTANCE; // name of the enum
  
  Singleton() { // Constructor is always private
    // constructor if needed
    myState = "VALUE"; 
  }

  private String myState;
  public void setValue(String myState) {
    this.myState = myState;
  }
}

If you set the value of myState before serializing the enum, the deserialization will return to the default value set in the constructor which is here “VALUE.” This is a possible limitation for using enum (as well as the impossibility to create subclasses).

Good tips about using a singleton

  • When to use a singleton? For example, we want to create a class that manages displaying maps. Should I use a singleton or a regular class? It seems it could be a singleton. A few questions can help decide:
    • Does the instance access resources that are shared?
    • Should we limit the creation of this class to only one instance? (What if we want to create another map section?)
    • Is it worth the effort to make it thread safe?
  • How to handle resources in the Singleton? A good idea is to use the principle of dependency injection to be able to test the Singleton as well as making sure it is adaptable. Let’s illustrate it quickly with a singleton managing database connections:
enum dbConnector {
  INSTANCE;
  ... // constructor

  public Connection getConnection() {
    DB database = new DB("Oracle"); // hardwire dependency
    return database.getConnection();
  }
}

We can inject the dependency to the database:

enum dbConnector {
  INSTANCE;
  ... // constructor

  public Connection getConnection(DatabaseManager dbMgr) {
    DB database = dbMgr.get("Oracle"); // the dependency is injected
    return database.getConnection();
  }
}

The Prototype Pattern

The Prototype Pattern has purpose to simplify the creation of complex objects by copying them. An existing (partially or fully constructed) design is a Prototype. Let’s illustrate this with a Recipe object:

class Recipe {
  List<String> ingredients;
  List<String> utensils;
  int timeToPrepare;
  int timeToCook;

  ...
}

Let’s say we want to create a bunch of cake recipe. We want to create a basic recipe that can be completed later:

Recipe prototypeCake = new Recipe();
prototypeCake.addIngredient("Flour");
prototypeCake.addIngredient("Eggs");
...
prototypeCake.addUtensil("Bowl");
prototypeCake.addUtensil("Mixer");
...

Now time for the most complex part of the pattern: cloning the prototype. It requires to deep copy every single property (when needed).

class Recipe {
   ...

   public static Recipe clone(Recipe toClone) {
      Recipe copy = new Recipe();
      copy.timeToPrepare = toClone.timeToPrepare;
      copy.timeToCook = toClone.timeToCook;
      toClone.ingredients.forEach(copy::addIngredient);
      toClone.utensils.forEach(copy::addUtensil);
   }
}

// The creation of other recipes becomes much easier
Recipe chocolateCake = Recipe.clone(prototypeCake);
...
Recipe strawberryCake = Recipe.clone(prototypeCake);
...
Recipe cheeseCake = Recipe.clone(prototypeCake);
...

The difficulty with cloning is the to figure out how to copy the whole tree of objects that is needed. What if the list of ingredients was not a list of String but of Ingredient objects?

List<Ingredient> ingredients;

class Ingredient {
  double quantity;
  String description;
  Quality quality;
  double price;
  ...
}

We would need to deep copy Ingredient, and Quality, etc… Another way to clone is to use Java’s serialization mechanism which allows to copy the whole tree of objects by values.

So now, we can customize the objects:

chocolateCake.addIngredient("Chocolate");
etc...

The Abstract Factory Pattern

“Abstract Factory” sounds barbarian… and I have seen a few variants. It was sometimes confusing and unclear.

The Abstract Factory pattern implements the dependency of injection principle for polymorphic objects. It reverses the responsibility to create objects from the object itself to another one called Factory. For example, we want to create a list of objects representing a mathematical operation.

// parent class
class Operation {
   public double operate(double x, double y);
}

A class can chain operations to sum up the results of each operation:

class Operator {
  
  public double perform(List<Operation> ops, double x, double y) {
 
    double res = 0;
    for (Operation op : ops) { // new style
       res += ops.operate(x, y)
    }
  }

}

Now we can have many different operations:

class Sum extends Operation {
   public double operate(double x, double y) {
     return x + y;
   }
}

class Minus extends Operation {
   public double operate(double x, double y) {
     return x - y;
   }
}

class Multiply extends Operation {
   public double operate(double x, double y) {
     return x * y;
   }
}

class Divide extends Operation {
   public double operate(double x, double y) {
     return x / y;
   }
}

These operations can be constructed following the abstract factory pattern. It is called “abstract” because it relies on at least an abstract parent that is implemented by concrete factories depending on what is needed to be created.

interface OperationFactory {
  Operation createOperation();
}

class SumFactory implements OperationFactory {
  Operation createOperation() {
     return new Sum();
  }
}

class MinusFactory implements OperationFactory {
   ...
}

etc.

// we need something (constructor, provider class, or inner builder class, etc.) to construct the factories
class FactoryProvider {
  public OperationFactory getFactory(String type) {
    switch (type)
       case "sum" :
          return new SumFactory();
       case "minus" :
          return new MinusFactory();
       ...
  }
}

The abstract factory pattern matches the factory polymorphism with the classes’ polymorphism.

It is obviously unnecessary in this case, but it would make more sense if we want to accomplish something more complex, such as creating different Operators with different Operations. Operator could perform operations by sub-operators. In that case, we may have something like:

interface OperatorFactory {

   Operator buildOperator();
   Operation buildOperation();
   Operator buildInterOperationOperator(); // operator performing an operation between different operations (other than simple sum as done previously), etc.
   Operation buildInterOperation();

}

class DistanceCalculatorFactory implements OperatorFactory...
class PowerFactory implements OperatorFactory...
class AbsoluteFactory implements OperatorFactory...

The Builder Pattern

The Builder pattern is useful when we want to create objects with many properties to set and to ensure their immutability.
Let’s illustrate this concept. Lately, I have been cooking marinaded meat. But as you can imagine, it is far better to have all the ingredients mixed before marinading the meat.

We could simply use the constructor to do it, but it is lengthy, and possibly difficult to call if not all the ingredients are ready by the time we want to invoke the constructor.

public class Marinade {
  private Ingredient soySauce;
  private Ingredient garlic;
  private Ingredient gingembre;
  private Ingredient brownSugar;
  private Ingredient onion;

  public Marinade(Ingredient soySauce, Ingredient garlic, Ingredient gingembre, Ingredient brownSugar, Ingredient onion) {
    this.soySauce = soySauce;
    this.garlic = garlic;
    this.gingembre = gingembre;
    this.brownSugar = brownSugar;
    this.onion = onion;
  }
}

The other possbility is to use setters.

public class Marinade {
  private Ingredient soySauce;
  private Ingredient garlic;
  private Ingredient gingembre;
  private Ingredient brownSugar;
  private Ingredient onion;

  public Marinade() {
    this.soySauce = soySauce;
    this.garlic = garlic;
    this.gingembre = gingembre;
    this.brownSugar = brownSugar;
    this.onion = onion;
  }

  public void setSoySauce(Ingredient soySauce) {
    this.soySauce = soySauce;
  }

  public void setGarlic(Ingredient garlic) {
    this.garlic = garlic;
  }
  …
}

The problem with setters is that the properties are mutable. In our case, we do not want such a thing. Once our marinade is made, it is too late! Here comes the Builder Pattern.

public class Marinade {
  private final Ingredient soySauce;
  private final Ingredient garlic;
  private final Ingredient gingembre;
  private final Ingredient brownSugar;
  private final Ingredient onion;

  public Marinade(Builder builder) {
    this.soySauce = builder.soySauce;
    this.garlic = builder.garlic;
    …
  }

  public static class Builder() {
    private Ingredient soySauce;
    private Ingredient garlic;
    private Ingredient gingembre;
    private Ingredient brownSugar;
    private Ingredient onion;

    public Builder() {}

    public Marinade build() { 
     return new Marinade(this); 
    } 

   public void soySauce() { 
     this.soySauce = soySauce; 
   } 

   public void garlic() { 
     this.garlic = garlic; 
   } 
   ...
  }
}

In our case, the builder is an inner class. To build a marinade, we simply need:

// also called Fluent Builder/Interface since it returns itself making the construction "fluent"
Marinade marinade = new Marinade.Builder()
    .soySauce(soySauce) 
    .garlic(garlic)
    …
    .build();

Simple and elegant… and the properties are immutable.