Design patterns: moving object references around an application

Question

I'm new to Programmers and I am looking to increase my knowledge of programming. Recently, a user on Stack Overflow told me using singletons is a bad idea, that they encourage tight coupling and that they make testing harder.

What prompted this discussion was that every class I've ever written accessed any kind of data through a singleton. For example, a class that handles state data for a game. If any other class wanted to access this data, all they would have to do is get the singletons instance and there it would be. Specifically, instantiating a class on the AppDelegate, then accessing it via: [[[[UIApplication sharedApplication] delegate] gameObject] getScore].

The SO user told me that I should instantiate the 'gameObject' wherever I first need it, then pass that object to every other class that needs it via either a method as an argument, or via a property.

I was discussing these points when someone else pointed out that this information is completely wrong, that singletons are unrelated to coupling and that they do not affect testing at all.

I'm now completely confused as to which person is correct. Could someone please clarify which technique is best for an object to persist for the lifetime of the app, and be accessible to other classes, and also maintain loose coupling. To me, the object passing by method or property to each class seems the most logical, but I do not know!

Thanks in advance for any help!

Answer 1

You won't ever know. Program design is about tradeoffs, and analyzing particular scenarios to produce a solution that is good (not best) given what you know about them. In this particular scenario, the singleton proponent is decidedly incorrect but you're missing the point.

In scenarios where the answer is less clear cut, you're going to need to be able to think things through yourself to judge what is a good or bad approach for the problem at hand. If you know what coupling is, and what a singleton is then you shouldn't really need to ask us. It's important to develop this skill for those many times when the particulars of the scenario mean we can't get you an answer.

Answer 2

The part that creates coupling isn't the fact that the variable lives in a singleton, but that your client object goes and fetches it from there itself. This means that you could never change the way your object is stored without introducing all kinds of hassle for yourself (assuming, as you say, that many objects behave this way).

Consider what would happen, for example, if you decided you wanted your program to be MDI (multi-document interface) so the user could play more than one game at once. Since your entire program accesses this singleton, you've pretty much screwed yourself.

On the other hand, you can store the game in the singleton and then inject it into objects that need to access it. Look up Dependency Injection. I don't know why you'd have a singleton at that point but maybe it wouldn't be completely pointless.

Basically, they're both right.

Answer 3

Regarding the Singleton, consider a case where you want to test a class that uses a Singleton, but you wish to mock it. You can do it by extracting a method called getSingleton and then overriding it in a testable subclass, but it gets messy this way.

Your class will be more testable if it accepts the dependency on the other class in the constructor. You can then inject a mock dependency in your tests.

If you apply this throughout your project, you will discover you don't need any Singletons anymore, but you do need to "wire" your project up basically from the main method.

Guice is a DI framework that helps with this, but I recommend playing with it manually first, so you learn the concepts.

If you want to learn more, I really recommend what Miško Hevery has to say.

Videos:

• http://googletesting.blogspot.com/2008/11/clean-code-talks-dependency-injection.html
• http://googletesting.blogspot.com/2008/11/clean-code-talks-global-state-and.html
• http://googletesting.blogspot.com/2008/12/by-miko-hevery-google-tech-talks.html

Blogs:

• http://misko.hevery.com/2008/09/10/where-have-all-the-new-operators-gone/
• http://misko.hevery.com/2008/07/08/how-to-think-about-the-new-operator/
• http://misko.hevery.com/2008/09/10/where-have-all-the-new-operators-gone/

Answer 4

At the end of the day, you have to do what makes the most sense you you. Singletons are fine. If they've worked for you, use them.

The problem with them is that you may need more than one of them someday. Your game program may want to juggle two or more games at the same time. Then you have track down every reference to your GameObject and replace it with something more elaborate. The cost of allowing multiple gameObjects from the start is a lot less than retro-fitting the capability later and only slightly more than sticking with a singleton GameObject for the whole life of the program.

If you are certain you will never have multiple games, it's cheaper to go with the singleton. (Although avoiding them might help improve your programming skills--it might be good practice for times when you can't use singletons.) Personally, I've spent enough time getting rid of singletons in my code that I'll avoid them now at all costs.

In your case, singletons are not related to coupling and do not affect testing at all (other than the complete retesting you have to do after removing them).

However, if your code responded to web HTTP requests, and hence might run in hundreds of threads simultaneously, accessing singletons (and, for that matter, any data visible to more than one thread) becomes very tricky. If you don't understand multi-threading programming real well, you are going to cause a major train wreck. The values in the singleton will change at any time. Bugs will be unrepeatable, because they depend on the precise timing of several threads. Reliable testing becomes impossible.

There are a lot of people doing this kind of programming. They don't understand multi-threading. And the people who have to clean up after them feel very strongly that they should not use singletons. This is what the user on SO is talking about. (I think he was advising you to create a new gameObject for each individual HTTP request.) I doubt this is relevant to you, but it helps to know what everyone is talking about.

Answer 5

Singletons are very much like global variables with a namespace. Almost all people tell you global variables are bad, but somehow, Singletons are ok.

Having said that, Singletons have some specific uses. It can be used when you definitely want one instance of something. For example - you want only 10 Database Threads, otherwise your database server will crash under load. Your ThreadPool class then should be a Singleton, and manage the DB threadpool.

Another use may be if you have read-only ( or rarely changing ) configs which are essentially global variables. In this case it would save memory and occasional file IO to have it as a Singleton.

In your example - you want to have a GameState as a Singleton. Why would you limit your program to one game? Even if you wanted one game initially, you are restricting yourself by putting singleton logic in the GameState class.

I'm not sure of your application - but I would have created a Game Object separately :

void startGame() {
    Game gs = new Game();
    gs.play();
}

Now how do we find the score? Depends on who needs the score. If I assume the Game class owns the score, then it can have a getScore() function. Sometimes a Player may need a score. This can be solved by letting the Players have a Game reference.

void startGame(Player[] players) {
    Game gs = new Game();
    for ( Player player : players ) {
        player.registerForGame(this);
    }
    gs.addPlayers(players);
    gs.play();
}
Player::registerForGame(Game game) {
    this.currentGame = game;
}

The code is not in any particular language - just an illustration of how it could be designed without singletons. Also, I don't claim this to be a "good" design - for example the Game class will probably to too much here, if the Game has lots of functionality.

As someone mentioned design is just a lot of tradeoffs and you have to do what makes sense for a particular problem.

Answer 6

Well, let's start with singletons.

I'm a JS/client-side web dev who has just recently decided to implement singletons. I'm writing UI objects that are somewhat monolithic in that they represent all UI elements of a given type on a page. The UI object is factory, warehouse, and event/interface manager.

The point in building and managing all instances of these UI elements of a given type from the same type-representing object is that sometimes in UI I want to deal with one UI element at a time and sometimes I want all of them to respond to the same event. Also, it makes it easier to create a more event-driven interface, which is something I've been geeking out on as of late.

But if I were to allow multiple factories from the same constructor, I'd have a nasty or at least clumsy time of trying to to hit all the UI elements with a global event, for instance, because each general UI type object instance would only have the references to UI elements that it actually built. Instead, my general UI type object factory methods will simply return a reference to the original objects when they've already been created. One Class/Constructor. One Instance.

The short version:

Singletons are about preventing multiple instantiations when having multiple instantiations might cause a problem. The end.

Now moving away from Singletons, the subject of tight-coupling:

Tight coupling is typically about excess dependencies. One big fat global object that's containing way too much state information without any means of verifying where that info came from might be problematic, but it's not tight-coupling. When things are too-tightly-coupled, I touch one function or object or random element of the environment (like say an HTML class on the web) and boom everything breaks.

Passing a reference to the same object around excessively and in weird/random ways could result in a tightly coupled-scenario, but mostly it's a good idea when you know your refs from your vars/properties that are getting passed by value and capitalizing on that knowledge wisely.

Answer 7

Decoupling has value if you plan on reusing your code (maybe making a multi-game server, for instance) or on creating unit tests for continued development or team development.

However, the time and effort to decouple your code might be completely wasted if you never reuse or need to further test your code (e.g. the game works, but doesn't sell well, so you move on to some other project). Furthermore, too much decoupling in the innermost loops of a compute engine (physics simulation, etc.) can actually waste a users battery life (e.g. not be "green").

The added value of decoupling might come into play if your game is a sleeper, starts to sell well next year, and your have to come back and read your code to update the app. Then decoupling to add readability, potential code reuse and testability will end up having value after all.

It's a trade-off and a gamble. Many large mission critical projects have to gamble that decoupling adds value (and almost always win that bet). For many small apps that go to die in an app store, the gamble may be a complete loss.