Facade Objects are often Singletons because only one Facade object is required.
Sometimes it's appropriate to have exactly one instance of a class: window managers, print spoolers, and filesystems are prototypical examples. Typically, those types of objects—known as singletons—are accessed by disparate objects throughout a software system, and therefore require a global point of access. Of course, just when you're certain you will never need more than one instance, it's a good bet you'll change your mind.
The Singleton design pattern addresses all of the previous paragraph's concerns. With the Singleton design pattern you can:Sometimes it's appropriate to have exactly one instance of a class: window managers, print spoolers, and filesystems are prototypical examples. Typically, those types of objects—known as singletons—are accessed by disparate objects throughout a software system, and therefore require a global point of access. Of course, just when you're certain you will never need more than one instance, it's a good bet you'll change your mind.
- Ensure that only one instance of a class is created
- Provide a global point of access to the object
- Allow multiple instances in the future without affecting a singleton class's clients
Note: You can download this article's source code from Resources.
The Singleton pattern
In Design Patterns, the authors describe the Singleton pattern like this:Ensure a class has only one instance, and provide a global point of access to it.
The figure below illustrates the Singleton design pattern class diagram.
Singleton class diagram
instance()
method. Example 1 shows a classic Singleton design pattern implementation:
Example 1. The classic singleton
public class ClassicSingleton { private static ClassicSingleton instance = null; protected ClassicSingleton() { // Exists only to defeat instantiation. } public static ClassicSingleton getInstance() { if(instance == null) { instance = new ClassicSingleton(); } return instance; } }
The singleton implemented in Example 1 is easy to understand. The
ClassicSingleton
class maintains a static reference to the lone singleton instance and returns that reference from the static getInstance()
method. There are several interesting points concerning the
ClassicSingleton
class. First, ClassicSingleton
employs a technique known as lazy instantiation to create the singleton; as a result, the singleton instance is not created until the getInstance()
method is called for the first time. This technique ensures that singleton instances are created only when needed. Second, notice that
ClassicSingleton
implements a protected constructor so clients cannot instantiate ClassicSingleton
instances; however, you may be surprised to discover that the following code is perfectly legal: public class SingletonInstantiator { public SingletonInstantiator() { ClassicSingleton instance = ClassicSingleton.getInstance(); ClassicSingleton anotherInstance = new ClassicSingleton(); ... } }
How can the class in the preceding code fragment—which does not extend
ClassicSingleton
—create a ClassicSingleton
instance if the ClassicSingleton
constructor is protected? The answer is that protected constructors can be called by subclasses and by other classes in the same package. Because ClassicSingleton
and SingletonInstantiator
are in the same package (the default package), SingletonInstantiator()
methods can create ClassicSingleton
instances. This dilemma has two solutions: You can make the ClassicSingleton
constructor private so that only ClassicSingleton()
methods call it; however, that means ClassicSingleton
cannot be subclassed. Sometimes, that is a desirable solution; if so, it's a good idea to declare your singleton class final
, which makes that intention explicit and allows the compiler to apply performance optimizations. The other solution is to put your singleton class in an explicit package, so classes in other packages (including the default package) cannot instantiate singleton instances.
No comments:
Post a Comment