Singleton is not a design pattern


Every morning i glance through the new questions on stackoverflow. This morning i found this on What is the real time use case of singleton bean scope?. I started answering, but soon found out i was giving the OP way more information than he/she needed. Also within the comments someone linked OP to another post.

I have had a long time problem with the "singleton pattern". Not its use case, but the fact it is named as a design pattern. In fact i believe it is just a hack for a shortcoming in c++ based languages (such as the Java Programming Languages and c# are). Rather it should be named an idiom for class-based oo-languages.

I should also probably mention i am no longer an advocate of imperative object-oriented programming. I lean, like many others, to functional programming.

What is a class again?

Whenever i teach (Java Developers) and i ask the group to name objects in the training room, they come up with "Student", "Chair", "Book", "Instructor". And of course they are wrong. These are not objects at all.

A class is a grouping concept by definition, grouping within a classification system. All tomatoes could belong to the class of fruits in a botanical classification system, and to vegetables in a retail classification system.

Here is the definition from

A set or category of things having some property or attribute in common and differentiated from others by kind, type, or quality

classes are typically defined by taking a group of objects and through the process of abstraction eliminate all non-relevant behaviour/aspects to a point where they can be classified as "within the same class".

For example with a classroom there are lots of people. Some may like classical music, whereas others are in to alternative rock and some are into contemporary pop music. Some have glasses, some have not. Some love to play tennis and others play video games. None of these things are relevant. What is relevant is that they registered for a course, perform exercises have lunch and require a workstation etc. So through the process of abstraction we end up with the similarities between these people and voilà the birth of a class: Student.

It is important to notice we started with a group of objects, then through the process of abstraction we were able to classify them, and we defined the "Class".

People using c++ based languages such as Java tend to only think in terms of these classes and not about the objects so much. Going back to the question: "name some objects in this training room", they should have replied "Mary", "Me", "station #22", "Raphael".

They named classes and not objects

So now what?

Ask yourself the question. Do you know the difference between an Object and an Instance?

Java is a class-based OO programming language (c++ style). This means every object which is ever going to exist at runtime, must be defined by a class. IOW Every object needs to be be an instance of a class.

This all makes sense when you have a group of similar objects. But what if you don't have a group? What if your object is one on its own. Rephrased: What if we want an object that does not belong to a group of objects?

If you would follow a very strict traditional object-oriented analysis approach you would never get to the concept of a "class". In old-school OO we start with objects, perform abstraction and group the similar ones. This would leave some objects "alone".

If we would then use a language that supports objects:

Example in Scala: scala object foo { }

Example in javascript javascript const foo = { } (I for one would have loved if in Scala we would use Pascal Case to identify objects)

But languages such as c++ do not support objects. So now we have a problem: we have objects that don't belong to a group of objects, but we have a language that forces us to use classes.

We need objects that are not instances. For those that need clarification on this: All instances are objects, but not all objects need to be instances. The word "instance" is always followed by "of «class»". An object like foo from above is an object who is not an instance of class.

Name some objects

Behavioural OO was really designed for domain-objects (defined by domain classes). Concepts from your domain (think Customer, Order). We will have many instances of these classes, each of them having a different state and an identity. We invoke methods on them so they behave and change their state.

For objects outside of the domain-model, things are often very different ("Technical classes" that deal with concepts such as ui, persistence etc.) What would be the difference between two student-database-helper classes, what would define their identity?

For a large bulk of these we need a single object and not a class of objects.

As a side note, there are a few good, and bad examples where we would need many instances of these technical classes. For example some objects that captures form data in a web application. There are frameworks which will have a class RegistrationForm and than an instance for each submission. Another example is stateless session beans (Java EJB). In the epoch where J2EE was born, it was though that developers could be protected from the horrors of threads and parallel processing. So they made the EJB model single-threaded. In order to get some level of through-put, an instance is created per request/thread. Something similar exist for message driven beans

The singleton idiom

As stated above, the majority of these technical objects would not require many instances. But we have languages that impose classes on us. This is where the singleton "design pattern" comes in. This pattern is a solution for class-based oo-languages in order to define classes for which there can/will ever be only a single instance.

But like i stated at the beginning: "i believe it is just a hack for a shortcoming in c++ based languages. Rather it should be named an idiom for class-based oo-languages."

I did not even go into the performance benefits of the "singletons". I took a top-down approach at the concept. There are however also many other benefits of using singletons. But i believe one would get the performance and problems in parallel computing all the way at the beginning when one tried to morph an object into a class.