The singleton is perhaps the most maligned software design pattern out there. It's right up there with the visitor pattern, which is often denigrated by developers as too complex. Yet, the notion behind singleton is simple: ensure that only one instance of a specific type exists during application execution.
The default Java behavior, as with most languages, allows you to create as many instances of a given class as you want. Up until J2SE 5, Java allowed no direct way to impose a restriction on the number of instances. In J2SE 5 and later versions, you can use the enum construct to constrain how many objects of a given type exist. You can also provide a unique name for each of these known instances.
In languages such as C and C++, an enum ("enumeration") is simply a series of integral values, where each element in the series maps to a unique symbol. The use of enums allows you to craft more expressive code. In Java, the enum is better viewed as a class like any other, except for a few key differences. An enum can have constructors, methods, and fields, but it cannot be subclassed. An enum definition first supplies the names of the known instances; no other instances can be created by any means.
From a simplistic standpoint, you could consider the catalog in a library system a candidate for a singleton. After all, you don't want to have to know what books were added to what catalog. Listing 1 shows how you might implement the catalog singleton using the enum construct.
Listing 1: The catalog singleton, expressed as an enum.
import java.util.*;
public enum Catalog {
soleInstance;
private Map<String,Book> books = new HashMap<String,Book>();
public void add(Book book) {
books.put(book.getClassification(), book);
}
public Book get(String classification) {
return books.get(classification);
}
}
Not much to it, is there? Client code must refer to the single known object, soleInstance (see Listing 2).
Listing 2: Accessing the enum singleton.
import static org.junit.Assert.*;
import org.junit.*;
public class CatalogTest {
@Test
public void singleBook() {
Book book = new Book("QA123", "Schmidt", "Bugs", "2005");
Catalog.soleInstance.add(book);
assertSame(book, Catalog.soleInstance.get("QA123"));
}
}
If you attempt to directly instantiate another Catalog object:
new Catalog(); // this won't compile!
...your code will not even compile, as the comment states.
Is this really a design pattern? Well, yes, it's an implementation of a design pattern, one that the Java language makes very simple.
Most developers are probably more familiar with the concept of "rolling their own" singleton. In Java, this means supplying a static-side creation method and making the constructor private. See Listing 3.
Listing 3: Hand-grown catalog singleton.
import java.util.*;
public class Catalog {
private static final Catalog soleInstance = new Catalog();
private Map<String,Book> books = new HashMap<String,Book>();
public static Catalog soleInstance() {
return soleInstance;
}
private Catalog() {
// enforce singularity
}
public void add(Book book) {
books.put(book.getClassification(), book);
}
public Book get(String classification) {
return books.get(classification);
}
}
The private constructor ensures that no other clients can create a Catalog object. From the client standpoint, things don't look very different (see Listing 4).
Listing 4: Accessing the hand-grown singleton.
import static org.junit.Assert.*;
import org.junit.*;
public class CatalogTest {
@Test
public void singleBook() {
Book book = new Book("QA123", "Schmidt", "Bugs", "2005");
Catalog.soleInstance().add(book);
assertSame(book, Catalog.soleInstance().get("QA123"));
}
}
Seems like a simple, harmless pattern. So what's all the fuss?
IE 7
Firefox 2.0
