Hey there, devs!
Despite the controversy surrounding Singleton — considered by some as an anti-pattern —, we first need to understand what it is and what it's used for, so we can draw our own conclusions.
Recently, while implementing a logger in an application, I came across the Singleton Design Pattern again. So, I thought about writing this mini article to share what I learned during my studies and my experience with this design pattern.
By definition:
Singleton is a Creational Pattern created to solve problems in object creation. It ensures that only one instance of a particular object exists and provides a single point of access to it for any other code.
But how does this really help?
Mainly by avoiding unnecessary creation of instances of objects that are frequently used in our application, thus reducing the system's memory consumption. That's great, isn't it?
Yes, but (there's always a "but") this doesn't always happen automatically. For the implementation to work correctly, you need to consider some points and specific contexts that you should be aware of.
First, let's understand how Singleton is implemented in an application.
- Must provide a single point of creation
- Must provide global access
- Must manage its own lifecycle
And there's one more point to consider: if your language works with multithreading, it's essential to be careful with synchronization in the creation and access to the Singleton to avoid concurrency problems.
Here we can already think of some scenarios where implementing Singleton would be advantageous for the application, such as:
- Logger, ensuring that all parts of the system use the same instance to record logs.
- Database connection instances, avoiding unnecessary creation of multiple connections.
- Sharing hardware resources, such as print drivers or access.
Like other Design Patterns, Singleton has both positive and negative points to consider:
We can note that sharing resources, controlling access, and performing singular operations are the positive points of Singleton. However, there are also some negative points to consider, such as testability. This is due to the creation of hidden dependencies, which results in coupling.
The violation of the "S" in S.O.L.I.D. is also a recurring point in Singleton implementation, precisely because of this dependency coupling. Additionally, if in the future you need multiple instances of this Singleton, you'll have to refactor the code, which can be a problem.
In the end, it all comes down to the trade-off: it's an exchange. For example, in the case of memory leaks, the choice between creating a new object or maintaining an existing object depends on which option is more advantageous in the context of your application.
So, is Singleton a friend or foe? It all depends on the context of your application, but I like to say that it's a good friend when necessary.
This is a more theoretical article, so I won't go deep into implementation in languages, as there are many examples readily available on the internet.
Thank you for reading this far! I hope I've helped and see you next time!
References
- Lucas Montano - Singleton explained like never before - Design Pattern
- Opus-software - Singleton Design Pattern
- Gabi Deuther - The use of Singleton Design Pattern
- Refactoring Guru - Singleton
Top comments (0)