The Clean Code Talks - "Global State and Singletons"

Google TechTalks · 194K views · 2008 · 54:09

Open on YouTube

Software architecture & designTesting, debugging & developer toolsSoftware practice, open source & careerstalk

Why Stack Overflow recommends it

Stack Overflow users link it when answering questions about Singletons, global state and testability, as the standard explanation of why Singletons hurt unit testing and why to use dependency injection instead.

Recommended by 40 people across 47 different months, 2009 to 2022.

Why Software Engineering Stack Exchange recommends it

Software Engineering Stack Exchange answerers point people to it when explaining why singletons, static methods and global mutable state hurt testability and hide dependencies.

Recommended by 2 people across 2 different months, 2011 to 2018.

What it is

A Google Tech Talk from the Clean Code Talks series in which Misko Hevery explains why global state and Singletons make code hard to test, debug and maintain. He separates enforced Singletons (capital S) from incidental singletons (small s) and shows how dependency injection avoids the problem.

What people said

Strong rec bambams · 2009-09 · Stack Overflow · on “Yeah.. I know.. I'm a simpleton.. So what's a Singleton?”

There was an excellent Google Tech Talk where the speaker addressed global state (including Singletons) and why they make testing nearly impossible: The Clean Code Talks - "Global State and Singletons" [this video] The speaker makes a distinction between what he calls Singletons (capital 'S'), where steps are taken to prevent the class from being instantiated more than once (i.e., often with a static getInstance method and private constructors), and singletons (small 's') where a single instance is all that is ever needed, but nothing is built into the class to prevent multiple instances from being created.

Strong rec Loki Astari · 2011-01 · Software Engineering Stack Exchange · on “The Singleton Pattern”

It has the same problems as a global variable. It gives you global accesses to mutable state. Anything that uses the Singleton is now tightly coupled to it. Try and avoid tight coupling. It makes the code hard to update. Hard to test. If your choice is a Singleton or global variable. Than at least Singleton provides lazy initialization. But usually it is best to avoid globally accessible mutable state and pass in all dependency to your code via parameters or in the constructor. This decouples your code from specific instances. Note: Global access to constant state is not such a big deal. Here is a good talk about the subject done by Google Engineers: [this video] Singleton pattern looks like it i

Strong rec Charles Sprayberry · 2012-01 · Stack Overflow · on “PHP Singleton instantiation with String class name”

A couple things really in regards to errors in using the "pattern" class Controller { private static $instance; /** * Initializes a new Singleton Controller */ private function __construct() { } /** * Get the instance of the Controller */ public static function getInstance(){ if (null === self::$instance) { self::$instance = new self(); } return self::$instance; } } Note that the property is now static and the constructor is private as necessary for this anti-pattern. Second your calling code should look like $instance = Controller::getInstance(); You should never have to instantiate 'Controller' from the outside; the point of the pattern is to only allow access through Controller::getInstan

Strong rec andrean · 2012-09 · Stack Overflow · on “python mock library - patching classes while unit testing”

I won't answer your question, but I recently found myself in a similar situation, used various hacks to make unittesting work, and then I stumbled upon the Clean Code Talks videos: [this video] Where you can find some excellent design-patterns, which will teach you how to write easily testable code, and you won't need hacks to be able to test your code. I highly recommend them to everyone.

Strong rec Ayush · 2012-12 · Stack Overflow · on “Should database exceptions be fatal?”

@cainmi: I'd recommend you watch this Google tech talk ( [this video] ). It really explains the inherent faults with singletons. It's a little long, but it's worth every minute of your time.

Strong rec Cristik · 2016-01 · Stack Overflow · on “Objective C - Creating singleton using shared instance”

The sharedManager is the convenience method you'd use to access the singleton instance. While this doesn't guarantee that there will be only one instance of that manager over the app, if everyone is using sharedManager then there will practically exist only one instance of that manager. This kind of singletons are singletons by convenience, not by implementation. You should use them, for multiple reasons: you can unit test them, by calling alloc init in your unit tests and making use of that brand new allocated object it makes your life easier if decide to later refactor the manager and no longer use it as a singleton if you consider it from the begging like a regular object to work with Of-

Recommends Joe Soul-bringer · 2009-01 · Stack Overflow · on “How do you write tests to test functions with variable return values?”

There's a Google Tech Talk [this video] good about dependency injection [LINK] . Basically, the ideal way to create testable code is to make all of your dependencies explicit so that you do not wind-up with situations where calling the same function twice can result in two different answers. In the case of dates and such, if you create an "system object" which you pass explicitly into your function, you could then create a "test system object" which could used for testing and which would return fixed values rather than returning the current date.

Recommends Chad Grant · 2009-05 · Stack Overflow · on “getting db connection through singleton class”

Your Singleton is still off. As far as the singleton pattern goes, please see Jon Skeet's very good and detailed description here : [LINK] Using a Singleton for a SqlConnection object is a really, really bad idea. There is no reason to do this whatsoever. If you are attempting to avoid a performance hit of "new SqlConnection()" or "connection.Open()" be advised that there really is no performance hit there because of the connection pooling going on behind the scenes. Connection Pooling handles the opening/closing of the expensive connections. Not the SqlConnection object. You won't be able to open multiple SqlDataReaders/Commands with the connection at the same time and will run into thread

Recommends Mike Weller · 2010-01 · Stack Overflow · on “Is it good programming to have lots of singleton classes in a project?”

I suggest you look at some of the videos and articles that Miško Hevery of Google has done. First a video: "Clean Code Talks: Global State and Singletons" [this video] and his blog [LINK] . The general concensus is that Singletons are OK in a few rare instances, for example logging, but in most other situations you want to use dependency injection. Singletons make it harder to test your code and they hide dependencies so that your classes cannot be instantiated easily in isolation.

Recommends Martin Törnwall · 2010-10 · Stack Overflow · on “Why is it hard to unit test a system that depends on singletons?”

This Google Techtalk [this video] does a pretty good job of describing the problems with singletons and global state when it comes to unit testing.