Easy patterns: Singleton
By this article I’m starting the series of simple and clear articles about architecture patterns. I would implement examples with JavaScript. Major target for me in these articles is to describe patterns in simple way with real examples from life and bring rememberable analogies. So you have clear idea in your mind. Currently you can find articles for such patterns:
Creational patterns:
Singleton (this article)
Structural patterns:
Behavioral patterns:
Main essence
Singleton helps to delegate object creation to separate function, which only can return new instances with minimum logic. That’s basically all it can do. It differs from static class or objects by not providing actual instance of created class but providing code structure which ensures you’ll get instance by strictly defined way. So, singleton — it’s a code structure, not a class instance. There must be exactly one instance of a class, and it must be accessible to clients from a well-known access point. (GoF book)
Profit
Singletons can delay their initialization because they can be dependent on some data that’s not available during application initialization. So, you can get an instance only when you need it — it saves runtime resources and makes it on demand flexible.
Use it with caution
Whilst we found ourselves needed to use this pattern, very often it’s a sign that the architecture of app should be re-evaluated. It’s an indication that modules are tightly coupled or logic is overly spread across many parts in application. Singleton could be more difficult to test due to hidden dependencies and stubbing them. Please refer to this article to read more about potential troubles with this pattern ibm.com.
Why is deferring execution considered important for a Singleton?
In many languages it serves to isolate from the unpredictability of the order of dynamic initialization, returning control to the programmer. It is important to note the difference between a static instance of a class (object) and a Singleton: whilst a Singleton can be implemented as a static instance, it can also be constructed lazily, without the need for resources nor memory until this is actually needed. If we have a static object that can be initialized directly, we need to ensure the code is always executed in the same order and this doesn’t scale when you have a large number of source files. Both Singletons and static objects are useful but they shouldn’t be overused — the same way in which we shouldn’t overuse other patterns. In practice, the Singleton pattern is useful when exactly one object is needed to coordinate others across a system.
Example
In this example we’re creating FetchId singleton. It exports only instance of Singleton, so we already ensured it will be safe. But, just in case somebody will extend this module with some logic, we providing enforcer symbol which prevents using class constructor directly. So, instance getter is the only place to instantiate class.
Conclusion
If you found this article helpful, please hit the 👏 button and feel free to comment below!
