The description of the pattern is simple. The class must be guaranteed to have only one object and this object should be granted global access. Reason for its stock is precisely the fact that it’s based on simplosity due to being just one class nothing complicated here. This is probably the easiest to study and implement the pattern.
The simplest implementation
As already mentioned, there’s nothing difficult in the following:
Make the class constructor private so that you cannot instantiate the class from the outside.
Store the instance of the class in a private static field.
Provide a method that will give access to this object.
Principle of sole duty
In object-oriented programming there is a rule of good tone. It’s referred to as the “Single Responsibility Principle”. The first letter in the abbreviation SOLID. According to this rule, each class must respond only for one aspect. Any Singleton class responds immediately for two things: for the fact that the class has only one object and for implementing the one for which this class was created at all.
The principle of a single duty was created for a reason. If the class is responsible for several actions, then by making changes to one aspect of the class’s behavior you can also touch the other which can greatly complicate the development. Also, the development complicates the fact that re-use or (reusability) of the class is almost impossible. Therefore it would be a good step to first make sure that the instance of the class is the only one from the class somewhere out. Secondly, to make the class, depending on the context, have the opportunity to stop being Singleton that would allow using it in different situations even depending on the need. As in with one instance with an unlimited number of instances and an limited set of instances and so on.
Testing
One of the main drawbacks of the “Singleton” pattern is that it greatly hinders unit testing. The “loner” brings the global state to the program. You cannot just take and isolate the classes that rely on Singelton. If you want to test a class, then you have to test with it and Singleton. It’s not so bad, just know the status of “Singles” can change which gives rise to the following problems:
- Tests can have undesirable third-party effects generated by Singleton;
- You cannot run multiple tests in parallel;
- Several calls to the same test can lead to different results.
Hidden Dependencies
Usually, if a class needs something to work with this is immediately understandable from its methods and constructors. When it’s obvious what kind of dependencies the class has it’s much easier to provide them. In this case you can use it instead of the really necessary dependencies of the stub for testing. If the class uses Singleton this may not be completely obvious. It all gets much worse if the instance of the class needs some initialization to work. For example, calling the init (…) method or something similar. Even worse, if you have several Singletons that need to be created and initialized in a certain order.
Class Loader
In regards to Java and ensuring the existence of only one instance of the class is required for Singleton actually becomes more difficult. The problem is that the classical implementation does not check if there is one instance on the JVM it just makes sure that there is one instance on the classloader. If you are writing a small client application that uses only one classloader then there is no problem. However, if you use multiple class loaders or your application should run on a server (where multiple instances of the application can run in different class loaders) everything becomes very sad.
Conclusion
Despite the fact that the Singleton pattern is very famous and popular it has many serious flaws. The more these shortcomings are revealed. The original patterns from the book GOF Design Patterns are often considered antipatterns in current times. While the idea of having only one object per class still makes sense but it is difficult to implement it correctly.
