I've been doing a lot of reading about how using singleton classes is becoming bad practice in programming due to hidden dependencies, hard to test etc etc.
A lot of forum posts I have read have said that you can still maintain a singleton's main functionality of only allowing one instance without using the singleton pattern.
I wondered if anyone could give a practical example of this. A lot of posts have suggested using a factory class to create singleton instances where the dependencies are clearly shown. To me this just seems like taking multiple singletons and combining them into a single factory singleton which would have the same problems?
Source: Tips4all, CCNA FINAL EXAM
The problem with the "singleton pattern" is really not with the singleton itself, but with the inflexible static factory method in the singleton class. And I believe that even in the GoF book, this was considered an example of how a singleton could be accessed, not the definitive implementation model.
ReplyDeleteA lot of posts have suggested using a factory class to create
singleton instances where the dependencies are clearly shown. To me
this just seems like taking multiple singletons and combining them
into a single factory singleton which would have the same problems?
The difference is that this single factory then becomes the single point where you maintain dependencies.
And in fact, the generally accepted solution is to use a dependency injection framework like Spring or Guice which is basically such a single factory with a very powerful and flexible configuration mechanism which can do much more than just manage singletons.
The solution is usually to use dependency injection. This doesn't mean you have to have a framework, you just need to create instances and connect them together externally to your main code base. I use a module which depends on everything else which wires and configures all the components externally (to the components which are in other modules)
ReplyDeleteUsing dependency injection, you have a singleton whenever you only create one instance.
Obviously, in tests, you can create many instances including sub-classes and mocks of interfaces.
A good practical example is the springframework. It creates beans by default as "singleton" (only one instance in the container), but there is no requirement that the programmer implement the pattern (private constructor, getInstance static method, etc.).
ReplyDelete