Singleton 🚣— design pattern
And why it actually matters for you to use it right
If you still haven’t seen, find my post about design patterns in general. You can find a list of explained design patterns in one place for free! 💰 Also read the article about Factory Method 🏭 or a Builder 👨🏭 pattern and how it fits with Singleton.
What is it?
Singleton ☝, as the name suggests, is about creating a single instance of an object. There are programmers who claim that Singleton is an anti-pattern 🤮. Please write that down:
Singleton is design pattern ✍️ and it’s very important to understand it
It would be very inefficient to write the code that would initialise objects every time we need them. Especially, when these objects are heavy. (Maybe it’s a good place to promote my other article 🧐 about lazy initialisation in Java). Smart heads figured out a way to reuse objects throughout entire app, knowing the consequences and danger that comes with it. Let’s be fair though, every solution can be dangerous 🤯, but used carefully brings only good. 🥴
It’s not hard to find examples of singleton candidates:
- 👍 Application instance — there’s always one,
- 🤙 Rest api service,
- 🤟 Database instance — singleton per DB connection string,
- 🖖 Cache instance — the one that should be accessible for entire lifecycle of the application,
- 🖐️ Session manager,
I would be able to list more examples 📝 depending on application size. Knowing that let’s get to example 👇.
It’s extremely easy to implement Singleton in Kotlin. Replace class with object keyword and it’s done! 💡
You can define singletons in Java on couple of different ways. Here’s two ✌ most common:
Notice that in Java, we need to make sure, no one can create 🚫 an instance of the Session class. For that reason, our default constructor must be private. Having private constructor prevents our class from creating another instance of the same class, but also such class cannot be derived from! 👬 The latter snippet is an enum-type which cannot be subclassed and only one instance can exist by default.
Pros & Cons
Just because you use a tool 🛠️ to handle scopes and Dependency Injection it doesn’t give you right to give up on best practices. Singleton pattern guards your class against unwilling object creations. Tell me, is using Dagger (Dependency Injection framework) prevents your class from being re-instantiated? No it doesn’t. You may be fully committed to DIP but there is another developer that pushes his changes when you’re away (sick leave, vacations).
The greatest advantage 💪 of using Singleton pattern is the fact that you don’t leave it to programmers to handle number of instances of your class. You actually leave them no choice — which is great! 🙌
Singleton can be a nuclear weapon 💣 if used recklessly. There are plenty of disadvantages for Singleton:
- Tight coupling — which is one of the cancers of software programming
- Mocks — singleton objects cannot be mocked
- Concurrency — Singleton objects can be a reason of bugs very hard to find
While concurrency is a topic for entire book and very hard, the first two bullets can be solved by following SOLID principles. Beware of using singletons on-the-fly. Tight coupling makes the code very hard to refactor, in fact, on some level just impossible.
It’s wise to treat Singletons as a 3rd party library 💃, which means, you should abstract the usage of it. This way you have a possibility to mock abstraction in tests, but have it used in a real app.
Did you like this post? Find more on my profile 👨 And don’t forget to clap 👏