Hey everyone In my other thread, where I talked about design patterns, I stated that a Singleton is definitely not a bad thing and might even be considered good practice. Now I want to elaborate on that again, because is this really true? I mean, leaving out the common answer here on the forum claiming that if you don't handle it properly it is definitely bad, because you can bring that up for everything. So are there still occasions or logical reasons for it to be considered bad? The answer is yes and no. It really depends on how you look at it. The idea of having a single instance of an object throughout the life of an application is definitely not bad at all and is really needed in some cases. Moreover, it makes many things way easier and thus keeps the code cleaner. Even the static instance aspect of it is not the worrying part. So what's wrong then? The real issues pops up when you start to run tests on those singletons. I mean, you can still do all your assertion tests, but at soon as you need to mock your singleton you start to see the issue; You can't mock it at all. The static method and private instance make it impossible for you to access the actual instance and mock it. In most scenarios, you might get away without mocking at all, but we need to see the whole picture. As soon as we want to test another class which depends on that singleton, we're screwed. There's no way for use to change the behavior in that case, even though we'll probably would need to. This also brings me to my next point. We don't directly see what a class really has of dependencies. We don't know that it uses this given singleton until we either get a NPE or look into the methods we're testing. This is definitely not great. I mean, sure, we won't run into this sort of issues at runtime, but tests should still be done and should still be possible to do, even in such an environment. In fact, those tests should ensure that we don't run into NPE's of those singletons at all times. But what about loggers? They're singletons too, right? Yes, but you have to separate them from the other ones. Singletons like loggers don't interfere with your program logic, they can easily be just left out and your program would still work completely fine. Again, there will be instances where you want things to be logged and thus probably still need to inject a mocked logger or something along those lines, but it's still far less worse than the things mentioned above. So do we just blame it on the tests and continue having fun with Singletons? Yes, errr no. Sort of. Testing is great so we can't just put it away. We just need to keep in mind certain things. Make the dependencies of a class visible by requiring them inside a constructor instead of using a static getter method. This already resolves most of the issues that'll come up. Apart from that, there's not really that much you can do without breaking the idea of a singleton, wich is not really what we're aiming for either. As you can see, the issue is not the idea itself, it is the implementation. I hope you enjoyed reading my post and I wish you a nice day ~kumpelblase2.