The term singleton is used interchangeably in Java to refer to two distinct concepts: an object that
has a single instance within the application, and the Singleton design pattern. We refer to the first
concept as singleton and to the Singleton pattern as Singleton. The Singleton design pattern was
popularized in the seminal Design Patterns: Elements of Reusable Object Oriented Software by Erich
Gamma, et al. (Addison-Wesley, 1995). The problem arises when people confuse the need for singleton
instances with the need to apply the Singleton pattern. Listing 4-70 shows a typical implementation of
the Singleton pattern in Java.
Listing 4-70. The Singleton Design Pattern
package com.apress.prospring3.ch4;
public class Singleton {
private static Singleton instance;
static {
instance = new Singleton();
}
public static Singleton getInstance() {
return instance;
}
}
This pattern achieves its goal of allowing you to maintain and access a single instance of a class
throughout your application, but it does so at the expense of increased coupling. Your application code
must always have explicit knowledge of the Singleton class in order to obtain the instance--completely
removing the ability to code to interfaces. In reality, the Singleton pattern is actually two patterns in one.
The first, and desired, pattern involves maintenance of a single instance of an object. The second, and
less desirable, is a pattern for object lookup that completely removes the possibility of using interfaces.
Using the Singleton pattern also makes it very difficult to swap out implementations arbitrarily, because
most objects that require the Singleton instance access the Singleton object directly. This can cause all
kinds of headaches when you are trying to unit test your application because you are unable to replace
the Singleton with a mock for testing purposes.
Fortunately, with Spring you can take advantage of the singleton instantiation model without
having to work around the Singleton design pattern. All beans in Spring are, by default, created as
Singleton instances, and Spring uses the same instances to fulfill all requests for that bean. Of course,
Spring is not just limited to use of the singleton instance; it can still create a new instance of the bean to
satisfy every dependency and every call to getBean(). It does all of this without any impact on your
application code, and for this reason, we like to refer to Spring as being instantiation mode agnostic. This
is a very powerful concept. If you start off with an object that is a singleton but then discover it is not
really suited to multithread access, you can change it to a nonsingleton without affecting any of your
application code.
■ Note Although changing the instantiation mode of your bean won't affect your application code, it does cause
some problems if you rely on Spring's life-cycle interfaces. We cover this in more detail in Chapter 5.
Changing the instantiation mode from singleton to nonsingleton is simple (see Listing 4-71, the
app-context-xml.xml file).
Search WWH :
