The Reluctant Global Variable

I don’t know many people who hate global variables as much as I do. I guess it’s an occupational hazard. I spend a lot of time going around helping people get existing code under test and globals are often a pain in that regard. If you have a global which modifies state, you want to make sure that you have some way to reset it at the beginning of each test. If you don’t, you have a state-leak which could make your tests behave erratically.

The Singleton Design Pattern is the commonest expression of a global variable in OO systems, and it’s interesting to notice just how much it clashes with unit testing. Traditionally, a singleton has a private constructor and a public static getInstance method.

// A Classic Singleton

public class Router {
    private static Router instance;

    private Router() { ... }

    public static Router getInstance() {
        if (instance == null)
            instance = new Router();
        return instance;
    }

   public void route(Message message) { ... }

   // all other methods
   ...

}

The two conspire together to make sure that you can only have one instance of the singleton, but they also leave you with a convenient way of making a global variable: all you have to do is call getInstance any place that you want to and you have your global. Now, in fairness, opinion in the industry has been moving toward using the singleton pattern just to ensure a single instance. There’s no reason why you have to call getInstance every time you use the singleton; you could just call it once and pass the object around. Unfortunately, few people do that. In many systems, you are pretty much stuck using various tricks to make code that uses your singletons testable. Here’s one:

public class Router {
    private static Router instance;

    protected Router() { ... }

    public static Router getInstance() {
        if (instance == null)
            instance = new Router();
        return instance;
    }

    public static void setTestingInstance(Router newInstance) {
        instance = newInstance;
    }

    ...
}

The setTestingInstance method allows you to swap out one singleton for another. Notice that the constructor is now protected also, so that the singleton can be subclassed to provide testing behavior. This solution isn’t great for everyone, but if you are one of the many people who use singleton not because you are terribly concerned about having more than one instance, but because it’s a convenient way of making a global variable, it’s a decent way to go. The thing is, once you’ve done that it’s legitimate to ask why you don’t you, as Uncle Bob put it: “just create one”?:

public class Router {
    public static Router instance;
    ...
}

The only advantage that a singleton with a setTestingInstance method has over a public variable is that not everyone is going to realize that setTestingInstance is there. If you want to have the illusion of a classic singleton, you can preserve it somewhat.

All this is fine, but I think that the thing that is key to understand is something that Uncle Bob pointed out earlier: the classic singleton pattern mixes two concerns: it is a mechanism for ensuring a single instance, and a mechanism for creating a global variable. There are, sadly, some times when all you need is the global variable. Here’s one:

I’m creating a testing tool for writing tests while refactoring. The key abstraction is something called a Vise. You use a Vise to grip values and record them for testing. The Vise has to be accessible in any code that you are about to refactor, so you don’t have the luxury of passing it down some call chain. You need to be able to just plop it in your code and go. And, there is only going to be one of them. So, here’s how you would make a call to the Vise if it used the classic singleton pattern:

Vise.getInstance().grip(value);

The fact is, however, that there is going to be just one instance in typical usage, but it’s not a hard design constraint. It would actually be more convenient for users if the call could look like this:

Vise.instance.grip(value);

Or even this:

Vise.grip(value);

How do we do that and still keep a flexible design? Well, we could use the following little pattern:

public class Vise
{
    public static IVise instance;
}

public interface IVise
{
    void grip(Object object);
    ...
}

Here we have a class Vise, which really is nothing more than a holder for a static variable. Is that good? Well, it’s not great; it’s a global variable, but it is flexible. The type of the instance variable is IVise and IVise can be implemented by a wide variety of classes, each of which we can set as the Vise for a session.

In the case of my little testing tool, I ended up creating a Vise like this:

public class Vise
{
    public static IVise vise = new DefaultVise(new InMemoryStore());
    ...
}

Vise also has a set of static methods which delegate to the IVise instance:

public class Vise
{
    public static IVise vise = new DefaultVise(new InMemoryStore());

    public static void grip(Object object) {
        vise.grip(object);
    }
    ...
}

And that enables a cleaner syntax while preserving flexibility:

Vise.grip(value);

So, this is just a variation of Uncle Bob's "Just Create One” pattern or Statically Initialized Non-Singleton (SINS) with an interface. The essence of it is this: if you need a global variable, and you aren’t concerned about malicious substitution at runtime, create a class which holds the variable publically. Consider making the type of the variable an interface so that you preserve your options: you can change the type of the actual class you use without impacting the variable’s clients.

One thing that is odd about it is that it is strange to have a situation where a class like, say, Vise, doesn’t implement IVise, but there’s no real need to. And, it’s very convenient to give the variable-holding class the general name; it becomes a known point of access in the system.


!commentForm