<story><title>So Singletons are bad, then what?</title><url>http://programmers.stackexchange.com/questions/40373/so-singletons-are-bad-then-what</url></story><parent_chain><item><author>Sandman</author><text>Doing x=C.get(x) is bad because there&amp;#x27;s no way of mocking C, thereby making unit testing a component that uses C impossible (the unit test will need to use the concrete implementation of C). Using dependency injection as described in the accepted answer, and particularly separating the concerns of C by using several different interfaces allows you to not only mock C, but actually create mock classes each of which is mocking one particular logical subset of C&amp;#x27;s functionalities.&lt;p&gt;It&amp;#x27;s easy to dismiss all this as &amp;quot;bloated&amp;quot; and &amp;quot;enterprisey&amp;quot; and people that use this as &amp;quot;architecture astronauts&amp;quot; but in reality, this pattern really does help. Well, at least if you want to be able to unit test your code properly. Otherwise, you might as well just use a singleton object.</text></item><item><author>shitgoose</author><text>Hilarious! Doing x=C.getX() is bad, but if it is hidden by numerous layers of libraries and monstrous config files, somehow it becomes acceptable. Out of site, out of mind. The fact that global scope bean is essentially a singleton, doesn&amp;#x27;t seem to bother architecturally inclined crowd - they are too busy admiring sound of their own voice pronouncing words &amp;quot;dependency injection&amp;quot;, &amp;quot;mutability&amp;quot; and &amp;quot;coupling&amp;quot;.&lt;p&gt;The top answer is a perfect example of what is wrong with IT today. It takes a working solution, declares it wrong and starts piling up classes and interfaces to solve a problem, that was never a problem in first place (OP never said that their singleton-based cache didn&amp;#x27;t work, he merely asked if there are &amp;quot;better&amp;quot; ways of doing it). So in the end we have the same singleton cache, but hidden behind interfaces (&amp;quot;It makes the code easier to read&amp;quot; - yea, right, easier, my ass! Ctrl+click on interface method and try to read the code),  thousand lines xml Spring configs, and other crap that is completely irrelevant, hard to follow and debug, but glamorous enough for SOA boys to spend endless hours talking about it.</text></item></parent_chain><comment><author>rdw</author><text>I realized recently that the reason that there is no way of mocking C is because of a weakness in the language implementation&amp;#x2F;design.  In Python, it&amp;#x27;s easy to mock and unit test globals, because in the test you can just overwrite them in the test&amp;#x27;s setup, and restore them in the test&amp;#x27;s teardown.&lt;p&gt;You could argue that it&amp;#x27;s a static vs dynamic typing thing, and I don&amp;#x27;t know enough to really dispute that, but it seems to me that there&amp;#x27;s no inherent reason that a static type system can&amp;#x27;t handle using a different concrete implementation.  I think you can do this with Java&amp;#x2F;C# by doing some library loading trickery, but it&amp;#x27;d be inconvenient.&lt;p&gt;And that&amp;#x27;s the whole point of all this, isn&amp;#x27;t it?  Automated testing is a convenience that saves you from doing manual testing.  Unit testing is a convenience that catches test failures before commit rather than during the automated testing phase.  Creating the unit test, well, is it more convenient to create 8 interfaces and completely change the way the code is structured, or is it more convenient to mock out the singleton?  It depends on the circumstance, I&amp;#x27;ve done both in various languages.  It&amp;#x27;s good to have the option.</text></comment>
<story><title>So Singletons are bad, then what?</title><url>http://programmers.stackexchange.com/questions/40373/so-singletons-are-bad-then-what</url></story><parent_chain><item><author>Sandman</author><text>Doing x=C.get(x) is bad because there&amp;#x27;s no way of mocking C, thereby making unit testing a component that uses C impossible (the unit test will need to use the concrete implementation of C). Using dependency injection as described in the accepted answer, and particularly separating the concerns of C by using several different interfaces allows you to not only mock C, but actually create mock classes each of which is mocking one particular logical subset of C&amp;#x27;s functionalities.&lt;p&gt;It&amp;#x27;s easy to dismiss all this as &amp;quot;bloated&amp;quot; and &amp;quot;enterprisey&amp;quot; and people that use this as &amp;quot;architecture astronauts&amp;quot; but in reality, this pattern really does help. Well, at least if you want to be able to unit test your code properly. Otherwise, you might as well just use a singleton object.</text></item><item><author>shitgoose</author><text>Hilarious! Doing x=C.getX() is bad, but if it is hidden by numerous layers of libraries and monstrous config files, somehow it becomes acceptable. Out of site, out of mind. The fact that global scope bean is essentially a singleton, doesn&amp;#x27;t seem to bother architecturally inclined crowd - they are too busy admiring sound of their own voice pronouncing words &amp;quot;dependency injection&amp;quot;, &amp;quot;mutability&amp;quot; and &amp;quot;coupling&amp;quot;.&lt;p&gt;The top answer is a perfect example of what is wrong with IT today. It takes a working solution, declares it wrong and starts piling up classes and interfaces to solve a problem, that was never a problem in first place (OP never said that their singleton-based cache didn&amp;#x27;t work, he merely asked if there are &amp;quot;better&amp;quot; ways of doing it). So in the end we have the same singleton cache, but hidden behind interfaces (&amp;quot;It makes the code easier to read&amp;quot; - yea, right, easier, my ass! Ctrl+click on interface method and try to read the code),  thousand lines xml Spring configs, and other crap that is completely irrelevant, hard to follow and debug, but glamorous enough for SOA boys to spend endless hours talking about it.</text></item></parent_chain><comment><author>shitgoose</author><text>Who says that you have to be able to mock C? Not every class should be mockable. In case described by OP, why would we want to mock cache anyways? In most cases singleton is used as a global state that can be easily accessed from all parts of the app without explicitly passing the state obj. We are dismissing a useful technique (singleton) based on requirement, that is not applicable to this technique.</text></comment>