The Singleton in the Physical World

The idea behind the Singleton is to ensure that there can be only one (insert Highlander jokes here). If you had a factory that made widgets, you would want a widget to be created many many times. But there is only one factory. If you were modeling the US government, you would only want one president. Only one senate.

The Singleton in the Software World

On the software side, the idea is the same. It is usually used when we only want one set of configuration variables, one controller, one data base connection pool, that kind of thing.

How do we do this?

Let’s back up a bit. Let us look at a very basic class that provides us with a code that is needed across our application.

public class MyClass {

   private long code;

   public MyClass() {
      code = Calendar.getInstance().getTimeInMillis();
   }

   public long getCode() {
      return code;
   }
}

public class MyClassTest {
   public static void main(String[] args) throws Exception {

      MyClass myClass1 = new MyClass();
      System.out.println(myClass1.getCode());

      Thread.sleep(500);// wait a bit to see if our code is the same

      MyClass myClass2 = new MyClass();
      System.out.println(myClass2.getCode());

      System.out.println("Oops. Different values.");
   }
}

If you only ever instantiated this class once, you are fine. But we haven’t done anything here to ensure that this is the case. There is nothing to stop someone from creating two MyClass objects.

Let’s start with the opposite. How do we create an instance of a class?

1
2

MyClass myClass1 = new MyClass();
MyClass myClass2 = new MyClass();

What can we do to ensure that only one instance can be created? Is there something else we have looked at that allows only one instance of a variable to occur? Static! We can use the static property.

public class MyStaticClass {

   private static long code = Calendar.getInstance().getTimeInMillis();

   public static long getCode() {
      return code;
   }
}

   public static void main(String[] args) throws Exception {

      MyStaticClass myClass1 = new MyStaticClass();
      System.out.println(MyStaticClass.getCode());
      System.out.println(myClass1);

      Thread.sleep(500);// wait a bit to make sure our code is the same

      MyStaticClass myClass2 = new MyStaticClass();
      System.out.println(MyStaticClass.getCode());
      System.out.println(myClass2);

      System.out.println("Ok. Same values.");
      System.out.println("Oops, different objects.");

   }
}

This time we have assigned a static variable our code, and provided a static method for accessing this code. Does this work? Somewhat. We only have one instance of code inside of MyStaticClass, but MyStaticClass is not guaranteed to have only one instance. This will get cumbersome to initialize as we add other data. It also results in a bunch of MyStaticClass.getCode() all over the application. What would be better would be to ask for this class just once, and then call getCode() as needed. How can we set that up?

The Simplest Singleton

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class Singleton {
 
   private static Singleton singleton;
 
   private Singleton() {
   }
 
   public static Singleton getInstance() {
      if ( singleton == null ) {
         singleton = new Singleton();
      }
      return singleton;
   }
}

This example doesn’t have our “code” in it, but it does show the elements of the singleton. We will add the “code” later.

There are some interesting things about this class. Look at the constructor. It is private! How does that work? We can’t do a “new” on this class! How can we create it? There is a private member variable that is static, and is of the same type as the class! It is a very strange sight at first glance. What is going on?

The constructor being private accounts for our first goal. No ability to call “new” on the object. If we can’t do a “new”, how can we create it? Well, we can do a “new”, but only from inside the class itself. We are doing that in the static getInstance() method. Look at what that method does. It first checks to see if an instance of the member variable singleton exists. If it doesn’t, it creates a “new” instance. This is the only place we will ever create an instance of the class Singleton. Therefore we have ensured that this is the only copy available. We then return singleton.

By doing things this way we have also lazy initialized the singleton. If we don’t need it, we never call getInstance(), and we never have to worry about the JVM allocating memory for something not used.

We also get a normal looking class out of it. We can have standard getters that are not static, and our application can pass this object around. It is easier to conceptualize the object used this way, and do maintenance later than a bunch of static methods seemingly randomly called within methods.

Can we actually do something?

Ok, I get your point. We need a bit more of an example. So here is a singleton with one “code” just like the others.

public class MySingletonClass {

   private static MySingletonClass singleton;

   private long code;

   private MySingletonClass() {
      code = Calendar.getInstance().getTimeInMillis();
   }

   public static MySingletonClass getInstance() {

      if ( singleton == null ) {
         singleton = new MySingletonClass();
      }
      return singleton;
   }

   public long getCode() {
      return code;
   }
}

public class MySingletonClassTest {
   public static void main(String[] args) throws Exception {

      MySingletonClass mySingletonClass1 = MySingletonClass.getInstance();
      System.out.println(mySingletonClass1.getCode());
      System.out.println(mySingletonClass1);

      Thread.sleep(500); //wait a bit to make sure our code is the same

      MySingletonClass mySingletonClass2 = MySingletonClass.getInstance();
      System.out.println(mySingletonClass2.getCode());
      System.out.println(mySingletonClass2);

      System.out.println("yea, same code");
      System.out.println("yea, same object");
   }
}

Look at that. Other than the singleton field, the constructor marked as private, and the getInstance() method, it is a pretty normal looking class. The constructor initializes our class just as we would expect. We can have pretty standard fields, like “code” with normal public getters.

Is that all there is to it?

Yup. It is that easy. Almost. Sometimes. There is one more wrinkle. Depending on how this singleton is being used, you may need to account for multiple threads. I am not going to get into that here, as we haven’t looked at threads yet. Keep in mind that if multiple objects could all call getInstance() at the same time, you may have an issue. Look it up, or wait and see if I get to threads eventually

Why use the pattern?

• Ensures only one instance of your code with minimal fuss.
• The singleton can be assigned.
• Uses lazy initialization to save memory.
• It is proven. It works. You can try to avoid the pattern, but why bother?

One of the reasons I picked this pattern to start with, is that it is very easy to understand. It models real word situations very well, and that is what OO design is supposed to do right, model real world objects?

The Adapter in the Physical World

The concept of an Adapter is easy to understand. It does just what it is named to do. It adapts one object to that of another. Take the wall plug. It has three rectangular holes set at angles to fit the plug. It does? In Europe it does. We are traveling and need to plug our laptop into the wall. What do we use? An adapter.

The Adapter in the Software World

The idea is not so different in the software world. When you want to connect one class to another class that was not designed to fit together, you need an adapter class. Let’s look at an Java example to see how we can adapt one class to another.

Adapting an Animal

In the last few lessons we have been dealing with the Animal interface. This is what it looked like:

1
2
3
4
5
6
7
8
9
10
11
12

public interface Animal {
 
   public void speak();
 
   public void move();
 
   public String getName();
 
   public void setName(String pName);
 
   public String getType();
}

We also had a BaseAnimal, but the idea was we were coding to this interface. So, keep in mind the speak() and move() methods. All the animals that we created implement these methods. What if we have a class that doesn’t implement Animal, but we want to treat as an Animal? For example, what if we found a really cool Reptile class out on the internet that we really wanted to use as an Animal, but it doesn’t implement our Animal interface. It doesn’t have speak() and move() methods. It has more specific methods hiss() and slither().

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class Reptile {
 
   public final void slither() {
      System.out.println("Reptile slithers.");
   }
 
   public final void hiss() {
      System.out.println("Reptile hisses.");
   }
 
   public final void snap() {
      System.out.println("Reptile snaps.");
   }
}

Options?

What can we do? What are our options? We could modify the code to have it implement the interface and change the method names to match our animal interface. That is probably a pattern that you have seen before, but it isn’t usually the best option.

What happens if the supplier, or coder of Reptile updates their code? Say, adds some code that improves the slithering? Every time you would have to install that class overtop of your changes, and then modify it again. That’s a lot of work. It usually means that upgrades don’t happen.

What happens if the supplier, or coder of Reptile only distributes a binary class? Are we SOL? Nope, Adapter to the rescue.

Take a look at this ReptileAnimalAdapter class:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

public class ReptileAnimalAdapter extends BaseAnimal {
 
   private Reptile reptile;
 
   public ReptileAnimalAdapter() {
      super();
      reptile = new Reptile();
   }
 
   public String getType() {
      return "reptile";
   }
 
   public void move() {
      reptile.slither();
   }
 
   public void speak() {
      reptile.hiss();
   }
}

What we have done, is use containment. The ReptileAnimalAdapter contains a Reptile. We don’t make any changes to Reptile, we just use it. Notice that it extends BaseAnimal, which implements Animal. Therefore, this Adapter meets all the requirements of our Animal interface contract. Look at the methods here. The ones we need to implement in here to finish the contract are getType(), move(), and speak(). We don’t change any methods on Reptile, we just adapt them to the Animal interface. When move is called, we call reptile.slither().

Let’s look at a class diagram of what we have now :

Animal Adapter Class Diagram

This diagram shows that a Reptile is contained within the ReptileAnimalAdapter that is extending the BaseAnimal class that is implementing the Animal interface.

Does It Work?

Take a look at AdapterTest1 to see how Reptile and ReptileAnimalAdapter work. This also shows how a ReptileAnimalAdapter “is a” Animal.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

/**
 * Test to look at our ReptileAnimalAdapter and see how it works. This will show
 * that we now have a "new" Animal type.
 *
 * @author Chris Ward 
 */
public class AdapterTest1 {
 
   public static void main(String[] args) {
 
      // Show what a Reptile looks like
      Reptile aReptile = new Reptile();
      aReptile.slither();
      aReptile.hiss();
      // note: see that move is not a method on Reptile by uncommenting this
      // aReptile.move();
 
      // Show that the ReptileAnimalAdapter can be used on it's own, and that
      // it no longer has the "slither" method.
      ReptileAnimalAdapter aAdapter = new ReptileAnimalAdapter();
      aAdapter.move();
      aAdapter.speak();
      // note: see that slither is not a method on the adapter by uncommenting this
      // aAdapter.slither();
 
      // Show that we now have a new animal that works just like any other Animal
      Animal aAnimal = new ReptileAnimalAdapter();
      aAnimal.move();
      aAnimal.speak();
   }
}

AdapterListTest1 also shows how ReptileAnimalAdapter “is a” Animal, by putting it in a Java5 Animal Typed list.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

/**
 * This test just shows that we can take our ReptileAnimalAdapter and add it to
 * a list of Animals, and use them as if they were simple Animals that move and speak.
 *
 * @author Chris Ward 
 */
public class AdapterListTest1 {
 
   public static void main(String[] pArgs) {
 
      // using Java 5 typed list. Only objects of type
      // Animal can go in this list.
      List animalList = new ArrayList();
 
      // if we don't need references to the animals
      // we create, don't create local variables for them.
      animalList.add(new Bird());
      animalList.add(new Fish());
      animalList.add(new ReptileAnimalAdapter());
 
      System.out.println("Moving animals:");
      // use a Java 5 "for each" loop to minimize typing.
      // using Java 5 typed lists we don't need casting.
      for (Animal aAnimal : animalList) {
         // we don't need to know what type of animal
         // we are moving, just that we want them to move.
         aAnimal.move();
      }
 
      System.out.println("Getting animals to speak:");
      // we don't need to know what type of animal
      // is speaking, just that we want them to speak.
      for (Animal aAnimal : animalList) {
         aAnimal.speak();
      }
   }
}

Review what we did.

So, what have we done with this adapter? Nothing new really. We have used some of the Java principles that we have talked about in a particular way, and called it applying the Adapter pattern. That is all that using patterns is.

1. We created a new class (ReptileAnimalAdapter) that extends a base class, or implements an interface, (BaseAnimal in this case) and call it an Adapter.
2. We used containment to hold an instance of the class we need to adapt. (Reptile)
3. We coded to the interface (of Animal), to adapt the methods of Animal to Reptile.

That’s it. Nothing too complicated or convoluted. Some of the patterns are more complicated than this one, but several are simple. The point, is that you now understand a pattern. The next step is learning to recognize the pattern when you see it, and learning when to use it when presented with a problem.

Now when someone says, “Hey, I found a cool FlyingFish class! Can we use it with our code?”. You can respond with “Sure, we just need an Adapter class!”

It does take some Java knowledge to be able to read, use and apply patterns, but I think we have seen enough Java and OO principles to start looking at patterns. It is good to start hearing about and seeing different patterns at any level of Java programming.

So what is a pattern? In the physical world, it would be a series of steps taken over and over again that could be written down and repeated. In the software world, it is not really a set of steps, but a software solution that people apply over and over again in their coding. Experienced developers have put these solutions together, and given their pattern a name. By looking at and studying patterns, we can take advantage of the experience of others, and learn from their solutions. One interesting thing about patterns, is that they don’t need to be language specific. If you learn about the Adapter or the Command pattern, you can apply that pattern to PHP, Ruby, or Java.

Resources

One of the original books on the topic is by the Gang of Four: Design Patterns: Elements of Reusable Object-Oriented Software (Amazon)

Sun on J2EE design patterns: http://java.sun.com/developer/technicalArticles/J2EE/patterns/

A list of common Java design patterns: http://www.fluffycat.com/Java-Design-Patterns/

Head First Design Patterns

If you would like a paper copy of something, I would recommend the Head First Design Patterns book. It’s by Freeman & Freeman, published by O’Reilly. (Amazon) This is a good book that doesn’t assume a high level of java knowledge (at least at the beginning) but does a great job of explaining patterns. It uses Java for the examples, and the different patterns often build on each other. Well worth a read for all levels of programmers.

Q & A Session

Q: What am I supposed to ask questions about?
A: Patterns. Anything that you want to ask about patterns is fair game.

Q: Well, don’t people just learn the pattern names so they can throw them around to sound important?
A: I hope not, but I am sure some people do. When we all learn patterns, it makes it easier to talk about designing code. When someone is helping you, and you both understand some patterns, it is easier to communicate.

Q: But can’t people just explain what they mean. Don’t we have enough acronyms and buzzwords already?
A: I sense that patterns make you nervous, but don’t be. Think of it this way. When someone says they FedEx something, we know what the steps they went through. They wrapped the package, dropped it off, FedEx picked it up, flew it across the country, put it in a truck, and delivered it. When someone says “I Googled it”, we know what they did. They used a computer, with a web browser, at Google’s site, to search the internet for something.

Q: Yea, Ok, but everyone knows what FedEx and Google are, not everyone knows patterns.
A: Bingo. Now your making my point. You now see the value when people understand a common language. All I am suggesting is that we all try to improve our language skills to make it easier to communicate.

Q: Alright, maybe it is a good idea to learn a few of them. Where did they come from anyway?
A: People have always looked to more experienced coders for help. It is likely that experienced people have already run across similar problems and found a good way to fix them. Kind of like keeping a tool box of solutions in your back pocket.

Q: So, then Patterns are just random code examples that people have collected?
A: No, they are more basic than that. One of the best early attempts to collect patterns into a published work was by the Gang of Four mentioned earlier. They recognized that there were clearly defined solutions to problems that could be applied to almost any computer language.

Q: Almost any computer language?
A: Patterns usually focus on object orientated design principles, like those that we have talked about in earlier sessions. Some of the patterns are much harder to apply to languages that don’t use objects.

Q: Learning about Patterns is just building on what we have been learning?
A: Exactly. We have talked about objects, classes, interfaces, abstract classes, containment, and inheritance. We will use all of these ideas and principles as we look at patterns.

Q: Ok, so if Patterns are so great, why haven’t you brought it up yet?
A: I have. Remember the last unit, on Reflection? We talked about a Factory. Guess what? That is a pattern. We just hadn’t named it as one.

Q: Cool. These aren’t so bad.
A: Alright, are you ready to look at some more then?

Q: Wait a minute. I was just skimming the Head First Design Patterns book. Don’t they use the Q&A thing in there a lot? Did you steal that idea?
A: I didn’t steal it. I just applied the Pattern.

Q: Ok, fine. What’s first?
A: The next pattern we will look at is the Adapter Pattern.