In paleontology, a missing link is a transitional fossil that fills the evolutionary gap between two recognized species, both in time and in phenotype.

Quite frequently in the course of software development, certain parts of a program are deemed global at some point in time: there never ought to be a need for more than one instance, nor the need for polymorphic handling of a similar yet distinct part. And sometimes, but not always, this initial impression is proven wrong, and the need for more than one instance arises. The consequences of such an error are usually quite extreme: a one-of global entity tends to be referenced by name, requiring a refactoring effort to convert it to a parameter everywhere this is needed. And so, developers are given the choice between going with the initial impression (with the risk of having to convert it) or ignore the initial impression (and spend time on something they might never need).

I propose here a missing link, a third alternative which implements a one-instance form with minimal effort, yet can be easily refactored into a several-instance if the need arises.

Of course, this applies only in situations where a doubt exists. If it is obvious right away that a given entity will be a several-instance entity, then it should be written as such from the beginning. Only in situations where the current state of the design (especially in Agile methodologies) only requires a single instance should this missing link be considered.

But first, a few background information about this.

Procedural and Objective

A while ago, I wrote a short article that discussed how procedural programming approached the issue of global state. The basic conclusions were that by grouping global state into modules, the number of possible interactions decreased, and those that occurred were made obvious by the structure of the code. As such, a procedural program is a set of stateful entities that interact with each other along a dependency graph.

So is an object-oriented program: stateful objects reference each other and communicate through message-passing. At runtime, there is therefore no major difference in this respect between an object-oriented program and a non-objective procedural program. The main difference is elsewhere. Objects, unlike modules, are rarely defined in the code: they are usually created dynamically at runtime. So, while the two dependency graphs may look the same, the object-oriented runtime dependency graph is a purely dynamic construct that can be altered at will, whereas the procedural runtime dependency graph is a static construct that is tightly mapped to the structure of the code.

The extensibility of object-oriented programming comes from the dynamic aspects of its dependency graph: if objects can be created, replaced and removed at will, even by the program itself, then the program will have a flexibility and adaptability that exceeds the static module skeleton of a traditional procedural program. On the other hand, the static module skeleton is easier to design and implement than a fully flexible object architecture where elements can be hotplugged—even with language support for object-oriented programming.

When you have to build a bridge, you don’t build a fully automated moving bridge just for the fun of it: if the simplest thing that could possibly work is a plain old suspended bridge with no moving parts, then this is what you do.

Remember that we’re considering here the case of a one-instance object being converted to a multiple-instance object even though there is no apparent need for it yet. Why is that more difficult than using the one instance directly?

• Polymorphism requires abstraction, and abstraction usually comes from having several instances—then you can identify what’s general and what’s specific. Trying to abstract a concept from a single instance will miss some general aspects that could have been useful, and keep some specific aspects that will limit extensibility.

• It’s easier to program something which makes sense. If having multiple instances does not make sense yet, then the programmer cannot rely on his instinct or his intuition to determine whether what he’s writing works or not, and the single-instance assumption might fight its way stealthily into the program anyway. Testing a multi-instance system when you only have one instance is quite difficult, too.

• When using multiple instances, one has to consider what scope they should exist in, and how they are propagated down. Of course, there’s the code required to have the multiple instances trickle down to where they are used. But the real difficulty is deciding what the correct scope is—and since there isn’t a reason yet to consider multiple non-global instances, it’s quite probable that such a decision will turn out to be wrong in the end anyway.

• Handling a flexible design is harder, mentally, than handling a fixed design. In a static module skeleton, the dependencies are clear and, when they are not, can be extracted from the code very easily. In a dynamic dependency graph, one has to think about how that graph will be constructed at runtime before they know whether a certain piece of code can affect a certain concept (especially if that concept is still a one-instance global).

As such, delaying the setup of a flexible and dynamic dependency graph as long as possible reduces the amount and difficulty of development efforts. The downside, of course, is the refactoring effort required if the initial assumption is proven wrong. A solution to this conundrum would keep the conceptual simplicity of a single-instance static skeleton, while having a code layout that can be easily changed to a multi-instance dynamic graph as soon as the reasons for such a change are discovered.

Singletons?

While often used to implement single-instance cases, the Singleton design pattern does not solve this issue: it is a pattern for representing the single instance, and the problem here is related to how the rest of the program refers to the instance. If all your code uses a certain instance by name, it does not matter whether that instance is a global variable or the instance of a singleton class: that code cannot use a second instance until it uses that instance by reference, and that reference is a parameter of some kind.

So, the choice of a singleton (or any other approach) to represent the instance is completely independent of any solution that could be found to this problem.

Bottom-Up Construction

An approach which can be used in many cases and leads to avoidance of single instances is bottom-up development. Since the system is being built bottom-up, most of the time when a module would need to access a single instance, that single instance has not yet been written or even designed yet. In that situation, the correct approach is to create an interface representing what the module expects, and have a parameter somewhere to receive an instance implementing that interface. Then, when the single instance is finally designed, it can be made to implement that interface (or adapt to it) and then passed as an argument to the relevant elements.

Bottom-up construction eliminates many of the problems related to handling single instances. That is, by refusing to assume anything about the object being used beyond its interface (including, of course, how many instances exist that implement that interface) development automatically deviates from the single-instance approach and can handle multiple instances automatically.

This does not solve everything, however. Bottom-up construction is notoriously ill adapted to fast development cycles, because the actual functionality of the program appears only when the top-level objects have been developed, which is at the end of the cycle. By contrast, with a top-down approach, the top-level object can be developed first and filled with mocks, and the mocks replaced with the actual functionality on the fly. Besides, bottom-up construction is also subject to violating YAGNI, because objects are created before their users exist (and may end up not existing at all).

The Missing Link

The key of the problem here is that directly converting a single-instance approach to a multiple-instance approach requires a lot of argument-passing: since the instances are manipulated through references, and those references are parameters, a lot of parameters are required to pass the instance from its point of creation (quite probably somewhere near the entry point) down to every part of the program that uses it. A possible solution would be do to as much of that work as possible (replacing as many of the global accesses as possible with references) without having to heavily increase the number of parameters.

Aside from global symbols, one other kind of value is available in functions without being passed as a parameter: member variables.

The Screen Design Pattern

The problem: methods of a class needs to access a global variable directly. Making that variable non-global is unnecessary right now, but might be necessary in the future.

The solution: have the class keep a screen member reference to the global variable. That reference is initialized in the constructor and used everywhere else. Member functions other than the constructor are never allowed to reference global variables.

What would be an example of refactoring using this pattern? Consider the original C# code:

public class GlobalUser
{
  public GlobalUser() {}
  public void MethodA() { Global.Instance.Use(); }
  public void MethodB() { Global.Instance.Use(); }
}

Methods in this code use a global instance. Let’s replace that with a member reference to the global instance:

public class GlobalUser
{
  private Global screen;
  public GlobalUser() { this.screen = Global.Instance; }
  public void MethodA() { this.screen.Use(); }
  public void MethodB() { this.screen.Use(); }
}

Using the pattern, the refactored code can be written straight away (instead of writing the original code and then refactoring it) without requiring mental effort, which means that using the pattern bears almost no cost (it only requires an additional member variable and an additional assignment in the constructor). And if the screened variable suddenly has to become non-global, only the constructor will be affected, saving precious time that would have been lost refactoring the methods as well.

Note that creating a property which returns the global variable (instead of a member variable assigned in the constructor) is equivalent in terms of writing the initial refactored code (the this.screen = Global.Instance is replaced with { get { return Global.Instance; } }), but does not have the same benefits when refactoring to remove the global instance because a connection will have to be made between the value returned by the property and the parameter received in the constructor, which requires more code. I therefore suggest using a member variable assigned in the constructor instead of a property.

Also note that the above can be seen as the preliminary step of a dependency injection and follows the same general idea as preparing your application for Spring.NET integration (for example). The difference is that the pattern does so at the class scale, and emphasizes development speed (using the pattern should be no slower than using the non-pattern approach) rather than external interoperability and flexibility.

Memory issues

Of course, storing a screen reference in every object might not be welcome. Some very small objects, such as vectors or polygons, cannot afford to store an additional reference because of the time and space overhead this would imply.

My suggestion in these situations is as follows: eliminate the global dependency altogether. Resist the temptation to have a certain small object frobnicate itself using a global instance, and instead have a larger object frobnicate the small objects. This makes the optimization more transparent (the small objects are now just bits of data without any kind of polymorphic behavior that are externally manipulated) and allows using the Screen design pattern on the larger object.

A singleton is a way of designing a part of an object-oriented system that was used frequently enough to deserve its own name: the Singleton Design Pattern. In practice, a singleton is a class which can only have one instance at any given time, and for which that unique instance is globally accessible.

The purpose of a singleton class is to represent a concept which, by its own fundamental nature, can only exist as a single instance. Sometimes, this happens because there are no technical solutions available to allow more than one instance of that concept, or sometimes because the solutions do exist but are too impractical or difficult to implement.

To determine the need for the Singleton Design Pattern in a practical case, one should then examine the following checklist:

1. Is there a need for the considered functionality to be grouped in an object?A valid reason for wishing to regroup the functionality as a single object is if you need to manipulate it as an object, for instance to implement an interface and use functions or methods that can be applied to that interface. Another valid reason is the existence of several values related to that functionality which should then be grouped as a single object.

   If there is no reason to group the functionality in an object (no values to represent state, no usage as an object implementing an interface), then it is preferable to use a function, method, or namespace instead.

2. Is there a need for the considered functionality to be grouped in a class?The alternative here is often initializing a global instance of an existing class to represent the functionality, instead of defining a brand new class for that purpose. For instance, even though the standard output of a program is by definition a one-instance-only concept, many implementations of the C++ std::cout are not singletons, but rather global variables initialized with a specific internal buffer that prints to the standard output (that buffer, in turn, is not a singleton because it provides no global access to its unique instance).

   If the difference in functionality is so wide that you would have to rewrite most of the class, then it is a good idea to create a brand new class. By contrast, if the difference is very small, then one can often get away with using an old class instead.

3. Is there a technical reason for which the considered functionality does not allow multiple instances of the class?If it is technically possible to create several instances of the class, then the use of a singleton is not warranted: one can simply create a global instance instead.

   Note that it is not enough to decide that more than one instance will not be needed to warrant the use of a singleton! The reason the singleton is used is because the represented concept itself, independently of any external reasons such as how it will be used by the program, does not allow the creation of multiple instances. If the program happens to only create a single instance, then this is a coincidence and not a technical limitation.

   Note that this is only an argument against preventing the creation of multiple instances: the other traits of the singleton pattern (being a class which has a globally accessible instance) are not necessarily discarded if this particular condition does not hold.

4. Is there a need for the unique instance to be globally accessible?The non-singleton alternative is the one used by std::cout : implement a singleton-like class (only allows a single instance) but use its unique instance locally to either initialize a global instance of another class or as a persistent local variable in a function or method.

   The question to be asked here is whether an observer outside the scope of the module or function you are working in needs to know of the existence of the singleton candidate, or whether the fact that the class extends a public interface is enough.

   If knowledge of the class’ existence is necessary, then a globally accessible instance is almost always warranted: there is no point in knowing about the class if one cannot access its instance, and there is no point in passing the instance of that class around while knowing it is the only one.

   On the contrary, if only the interface is public, then only the module which contains the class needs to know about the class (and provide it to the outside world as that interface).

   This is an argument against making the instance a global variable: the other traits of the singleton pattern (the limitation to a single instance, for instance) still hold even if the instance itself is not global.

If the candidate satisfies the above four conditions, then it can accurately be described by the Singleton Design Pattern.

Monostates

The Monostate Design Pattern is a close relative to the Singleton Design Pattern, in terms of applicability. Almost every concept which can be implemented as a singleton can also be implemented as a monostate.

A monostate is a class which can have any number of instances, but where every instance has exactly the same state as all others. In terms of implementation, it is equivalent to a singleton: a monostate can be represented as a proxy class which automatically references the unique instance of the singleton, and the singleton can be used in place of a monostate simply by using the singleton’s global instance access function wherever the code created a new monostate.

From a design point of view, I tend to consider monostates as a globally weaker alternative to singletons. My reasoning is that a programmer makes the basic assumption that the state of a given instance can only be modified through references to that instance. However, a monostate violates this assumption by allowing the state of an instance to be modified through a reference to another instance. This oddity does not exist for a singleton, where only a single instance exists.

Of course, a monostate does have an advantage whenever the represented concept allows modifications of its state outside of a reference to its instance: this happens, for instance, when representing an entity which evolves outside the program (a filesystem, controlled hardware…) and which explicitly violates the above assumption. If that is the case, then it is interesting to use a FooBarView monostate to represent the concept of FooBar so that the name implies that the object itself is only one of many different views over the same autonomous concept.

Therefore, as a rule of thumb, if a hesitation exists between using the Singleton Design Pattern and the Monostate Design Pattern, then one should use a singleton unless by its very definition the represented unique-and-global-state will change outside the application.

Misconceptions

The Singleton Design Pattern carries several misconceptions, which often lead to its misuse in a situation where it is not an accurate representation of the concepts at hand (and thus a need for refactoring when the mismatch between pattern and concept becomes clear) and to the usage of unrelated arguments in defense of its use.

1. “I will use the Singleton Design Pattern because using global variables is not good object-oriented practice.” This is the single most encountered misuse of the pattern. It often finds its roots in the affirmations that “global variables are evil” (and thus should be avoided) and that “design patterns enforce good design” (and thus should be used). Both affirmations are incorrect, or at least partially erroneous.

   First, global variables are not evil in themselves. What is dangerous is a hard-coded reference to global mutable state : the fact that a piece of code is bound by its very implementation to a bit of mutable state, so that this binding cannot be altered or customized by the user of the code. The hard-coded binding is what makes the code difficult to reuse and thus creates a bad object-oriented practice. However, both global variables and singletons, when accessed directly by the using code, create that same hard-coded binding, and thus share the same issue (which stems, in fact, from the need to have hard-coded access to global mutable state, regardless of how that state is represented).

   Then, design patterns are not a silver bullet which automatically enforces good design. Design patterns are bits of high-level vocabulary which allows one to describe a situation or problem using fewer words, which lets the brain focus on the relevant words instead of the details. Using a design pattern to describe something which does not fit that pattern, however, is akin to calling “a tool which is used to drive nails into planks” a “hammer”: you will be in trouble when you notice the “hammer” was in fact a “nailgun”.

   In short, using a singleton to replace a variable is a misuse of the design pattern, which violates the third prerequisite (the impossibility to have more than one instance).

2. “I will use a singleton to correct a technical issue related to the use of global variables, even though that issue does not prevent the creation of multiple instances.” The technical issues often cited here are the resolution of the initialization order problem (making sure that a global will be initialized before another variable which needs to use it during its initialization) and the possibility of lazy creation (a global variable might exist in memory for a while even if the program never uses).

   The Singleton Design Pattern can solve these issues. However, the techniques it uses are orthogonal to the techniques used to restrict it to one instance only. Therefore, using a singleton to solve the problem and then removing the one-instance restriction (usually by making the constructor public) will result in a more accurate description, and is thus preferable to both singletons and global variables.

3. “I will only ever need one instance of this class, therefore I will use a singleton.” This violates the third prerequisite, and possibly also the fourth. Again, a singleton represents the inability for an additional instance to be created. If your object could be safely instantiated twice, but the application you are writing only uses one instance, then adding code to enforce the uniqueness of the instance is both in contradiction with the nature of the concept you are representing (because it supports multiple instances) and completely useless (because the application never attempts to create two instances anyway).

   If the third prerequisite is not satisfied, there are plenty of alternative solutions to use to achieve your goal (the most elementary example being the implementation of a singleton minus the one-instance-only restriction).

4. “I have made this a singleton, so that I don’t have to pass it to everywhere it is needed.” This is a violation of the first prerequisite. The only reason to turn some functionality into an object is because you wish to group the related state together in a manner which can then be manipulated by functions as a local variable, an argument or a return value.

   If your representation of the concept at hand does not involve any such manipulation, then a far better representation is to use a good old procedural interface for the concept. If your code could be rewritten with minimal to a procedural solution (by replacing the get-instance-and-call-method statements with call-procedure statements), then your code is implicitly procedural: correct object-oriented code is usually much harder to convert to procedural style. Therefore, since your code is procedural, it is both easier and more transparent to represent it using procedural means than by diverting object-oriented means from their intended purpose.

   A correct object-oriented use of the Singleton Design Pattern involves using the singleton class to implement an interface, and then pass the singleton to code which is applied to that interface. And so, not only does a singleton not avoid passing the instance around, but it requires doing so.

Advantages

The main advantage of the singleton is that it is a design pattern: a name which can be instantly associated by any remotely competent software engineer to a the elementary properties of “only one instance” and “globally accessible”. This is an exceedingly important notion: instead of spending precious time writing documentation which painstakingly describes the exact behavior of a given piece of code, being careful not to imply false properties and to be exhaustive in your enumeration of all cases, and also having the user read that entire documentation twice to make sure he understood it correctly, you can simply describe the class’ instantiation policy as “Singleton” and be done with it.

Sometimes, if the intended usage of a public library class is to use a single provided global instance (even if there is no technical reason to limit yourself to a single instance) provided by the library, then I would perhaps go as far as label that class a singleton, in order to forward the point of intended usage despite the violation of prerequisite three.

However, for a class that is to be used internally, and where the users of the code are also its developers, I would not consider mislabeling: conveying a meaning which is incorrect to an user is acceptable, because the user is not expected to know about the implementation (and, for all he knows, perhaps there is a technical limitation on the number of instances), whereas conveying an incorrect meaning to a fellow developer is not.

The special treatment provided to classes in several programming languages make singletons and monostates preferable alternatives to normal procedural modules. For instance, PHP5 provides autoloading support for classes (the file for a class is loaded when that class is used in the source instead of having to be loaded manually beforehand) which makes class-based implementations of modules better. Similarly, since ECMAScript provides no namespace functionality, using a single-instance global-access object as a namespace is a valid and somewhat frequent approach.

Conclusion

A singleton is an excellent tool for describing an unique and globally accessible concept, and there is a simple checklist to determine whether a concept qualifies for representation as a singleton. However, using the singleton design pattern to represent a concept which does not have the two required properties (for instance, by altering the concept by force to make it fit) generally causes more harm than good, by misrepresenting the actual concept being manipulated.