Singleton (GoF) - UML

The ServicesFactory raises another new problem in the design: Who creates the factory itself, and how is it accessed?

First, observe that only one instance of the factory is needed within the process Second, quick reflection suggests that the methods of this factory may need to be called from various places in the code, as different places need access to the adapters for calling on the external services. Thus, there is a visibility problem: How to get visibility to this single ServicesFactory instance?

One solution is pass the ServicesFactory instance around as a parameter to wherever a visibility need is discovered for it, or to initialize the objects that need visibility to it, with a permanent reference. This is possible but inconvenient; an alternative is the Singleton pattern.

Occasionally, it is desirable to support global visibility or a single access point : a single instance of a class rather than some other form of visibility. This is true - for the ServicesFactory instance

  • Name : Singleton
  • Problem : Exactly one instance of a class is allowed - it is a "singleton." Objects need a global and single point of access.
  • Solution : Define a static method of the class that returns the singleton.

For example, Figure shows an implementation of the Singleton pattern.

Figure 26.6 The Singleton pattern in the ServicesFactory class.

Applying UML: Notice how a singleton is illustrated, with a '1' in the top right corner of the name compartment.

Thus, the key idea is that class X defines a static method getlnstance that itself provides a single instance of X.

With this approach, a developer has global visibility to this single instance, via the static getlnstance method of the class, as in this example:

public class Register {
public void initialize() {
... do some work ...
// accessing the singleton Factory via the getlnstance call accountingAdapter = ServicesFactory.getlnstanceO.getAccountingAdapter();
... do some work ... }
// other methods...
}//end of class

Since visibility to public classes is global in scope (in most languages), at any point in the code, in any method of any class, one can write SingletonClass.getlnstanceQ in order to obtain visibility to the singleton instance, and then send it a message, such as SingletonClass.getlnstanceQ. doFooQ. And it's hard to beat the feeling of being able to globally doFool

Implementation and Design Issues

A Singleton getlnstance method is often frequently called. In multi - threaded applications, the creation step of the lazy initialization logic is a critical section requiring thread concurrency control. Thus, assuming the instance is lazy initialized, it is common to wrap the method with concurrency control. In Java.for example:

publicstaticsynchronized ServicesFactorygetlnstance() {
if (instance = null) {
// criticalsection if multithreaded application instance = new ServicesFactory(); }
return instance; }

On the subject of lazy initialization, why not prefer eager initialization, as in this example?

public class ServicesFactory
// eager initialization
private static ServicesFactory instance new ServicesFactory();
public static ServicesFactorygetlnstance() {
return instance;
// other methods.

first approach of lazy initialization is usually preferred for at least these reasons:

  1. Creation work (and perhaps holding on to "expensive" resources) is avoided, if the instance is never actually accessed.
  2. The getlnstance lazy initialization sometimes contains complex and conditional creation logic.

Figure 26.7 Implicit getlnstance Singleton pattern message indicated in the UML because of the T mark.

Another common Singleton implementation question is: Why not make all the service methods static methods of the class itself, instead of using an instance object with instance - side methods? For example, what if we add a static method called getAccounting Adapter to ServicesFactory. But, an instance and instance - side methods are usually preferred for these reasons:

  1. Instance - side methods permit subclassing and refinement of the singleton class into subclasses; static methods are not polymorphic (virtual) and don't permit overriding in subclasses in most languages (Smalltalk excluded).
  2. Most object - oriented remote communication mechanisms (for example, Java's RMI) only support remote - enabling of instance methods, not static methods. A singleton instance could be remote - enabled, although that is admittedly rarely done.
  3. A class is not always a singleton in all application contexts. In application X, it may be a singleton, but it may be a "multi - ton" in application Y. It is also not uncommon to start off a design thinking the object will be a singleton, and then discovering a need for multiple instances in the same process. Thus, the instance - side solution offers flexibility.

Related Patterns

The Singleton pattern is often used for Factory objects and Facade objects - another GoF pattern that will be discussed.

Conclusion of the External Services with Varying Interfaces Problem

A combination of Adapter, Factory, and Singleton patterns have been used to provide Protected Variations from the varying interfaces of external tax calculators, accounting systems, and so forth. Figure illustrates a larger context of using these in the use - case realization.

This design may not be ideal, and there is always room for improvement. But one of the goals strived for in this case study is to illustrate that at least a design can be constructed from a set of principles or pattern "building blocks." and that there is a methodical approach to doing and explaining a design. It is my sincere hope that it is possible to see how the design in Figure arose from reasoning based on Controller, Creator, Protected Variations, Low Coupling, High Cohesion, Indirection, Polymorphism, Adapter, Factory, and Singleton.

Note how succinct a designer can be in conversation or documentation when there is a shared understanding of patterns. I can say, "To handle the problem of varying interfaces for external services, let's use Adapters generated from a Singleton Factory." Object designers really do have conversations that sound like this; using patterns and pattern names supports raising the level of abstraction in design communication.

Figure 26.8 Adapter, Factory, and Singleton patterns applied to the design.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

UML Topics