The singleton architectural pattern is a well-known model for designing software solutions. It’s primarily known as a pattern for creating single instances for an entire software application. However, there are some caveats to its use that we’d like to share with you. Below, we’ll explain why the singleton is considered a design antipattern.

1. Introduction

A singleton, as its name suggests, is a “bachelor,” since it is a single instance and cannot be part of a collection of objects.

Its creation is primarily delegated to its own constructor. In other words, it is a class that creates itself. Its role is widely known and popular when defining utilities in projects, for example, the use of loggers, auxiliary functions such as calculations or string encryption, among others.

2. The pattern

2.1. Class diagram

2.2. Composition

The singleton consists of the following:

• The instance of itself, final, static, and private.
• A private constructor, which overrides the default constructor, preventing its creation by other classes.
• An instance callback function.

2.3. Implementation

public class MySingleton {
    private static final MySingleton INSTANCE = new MySingleton();

    private MySingleton (){}

    public MySingleton getInstance(){
        return INSTANCE;
    }
}

2.4. Uso

public class App {
    public static void main(String[] args){
        MySingleton singleton;
        singleton.getInstance();
    }
}

3. Advantages

• It’s a simple pattern to implement.
• Low implementation cost.
• Easy access from any point in the system.

4. Desventajas

The singleton pattern is not a recommended pattern. There are multiple articles that recommend against its use. Below, we’ll look at the reasons why it should not be used.

• It is not possible to determine at what point in an application the singleton is called, ergo, instantiated, which implies a lack of control over the creation of said singleton.
• Data management is generally inflexible. For example, if a single instance is used for uncontrolled calls such as threads or HTTP calls, the state of the object cannot be easily determined, which implies no control over the data contained in the instance.
• If an object must be cloned, the purpose of this pattern, which is to maintain a single object instance, is lost.
• For all the above reasons, a singleton is a very difficult pattern to test.

5. When to use it

It’s possible to implement it when a framework requires the creation of a sigleton object for its management (as is the case with beans in SpringBoot), since its management is delegated (outsourced).

In applications without frameworks, it’s possible to use them in programs where concurrency isn’t required and they aren’t large.

6. Alternatives

The Dependency Injection pattern provides an orderly and responsible way to create objects throughout an application. Since it provides a single way to manage the necessary created objects, this pattern allows for cleaner control over object creation and information transmission.

7. Conclusiones

The singleton pattern should be used with caution, and if possible, it’s best to find alternatives to its use. We strongly recommend against it since there are better alternatives. However, it’s necessary to consider its use in applications where concurrency isn’t essential, and where the creation of the singleton instance isn’t so important.

If you liked the content and find it acceptable to stay up-to-date with our posts, subscribe to the social media channels we manage in the footer or sign up to receive emails about new posts. Also, if you think we’ve missed something or would like us to delve deeper into a specific topic, please let us know in the comments.