The singleton pattern is one every developer must know. It is a class which has only one instance, which is handled inside it. You can only get the instance, but never (reflection etc excluded) create a new instance.
- It can be used multithreaded without further notice, because the state is handled in the one instance
- The implementation is good encapsulated.
- single point of access
- leads to a god class with too many code and too many responsibilities
- Unit-Testing can be difficult
- you may need a setter method for the instance or mocking framework
- Hides dependencies
- The possibilities of extensions are limited.
The question is do you really need a singleton?
In some cases you would instantiate it anyway only one time (e.g. in the field declaration) of the calling class, then just make a normal class. “You ain’t gonna need it” (the singleton).
You can create a usual interface and implementation and as default implementation use the singleton you would have used. Then inject it where you need it.
Don’t get me wrong I really like the Singleton Pattern, but you should ask yourself if it is really needed. Maybe it can be avoided. Here you can find maybe some more alternatives.