Applying the Singleton Pattern to the Case Study

In Chapter 14, I encapsulated the rules about taxes within strategy objects. I have to derive a CalcTax class for each possible tax calculation rule. This means that I need to use the same objects over and over again, just alternating between their uses.

For performance reasons, I might not want to keep instantiating them and throwing them away again and again. And, while I could instantiate all of the possible strategies at the start, this could become inefficient if the number of strategies grew large. (Remember, I may have many other strategies throughout my application.) Instead, it would be best to instantiate them as needed, but only do the instantiation once.

The problem is that I do not want to create a separate object to keep track of what I have already instantiated. Rather, I would like the objects themselves (that is, the strategies) be responsible for handling their own single instantiation.

This is the purpose of the Singleton pattern. It allows me to instantiate an object only once, without requiring the client objects to be concerned with whether it already exists or not.

The Singleton could be implemented in code as shown in Example 16-1. In this example, I create a method (getInstance) that will instantiate at most one USTax object. The Singleton protects against someone else instantiating the USTax object directly by making the constructor private, which means that no other object can access it.

Example 16-1. Java Code Fragment: Singleton Pattern
class USTax {
  private static USTax instance;
  private USTax():
  public static USTax getInstance() {
    if (instance== null)
      instance= new USTax();
    return instance;
  }
}

The Singleton Pattern: Key Features

Intent You want to have only one of an object but there is no global object that controls the instantiation of this object.
Problem Several different client objects need to refer to the same thing and you want to ensure that you do not have more than one of them.
Solution Guarantees one instance.
Participants and Collaborators Clients create an instance of the Singleton solely through the getInstance method.
Consequences Clients need not concern themselves whether an instance of the Singleton exists. This can be controlled from within the Singleton.
Implementation

  • Add a private static member of the class that refers to the desired object (initially, it is NULL).

  • Add a public static method that instantiates this class if this member is NULL (and sets this member's value) and then returns the value of this member.

  • Set the constructor's status to protected or private so that no one can directly instantiate this class and bypass the static constructor mechanism.

GoF Reference Pages 127–134.

Figure 16-1. Standard, simplified view of the Singleton pattern.



..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.222.197.35