At first I was inclined toward your stance on using a simple global variable which is init’ed perhaps, with the app startup. Upon reflection however, I’m not sure I see the difference between this and the singleton pattern, other than that the later packages the global variable (as a static) and has a self contained initialisation. Some might even argue that this is more in keeping with Single Responsibility Principle. What do you think?

Thanks for the thought provoking and detailed discussion by the way. It’s very pertinent to the code I’m writing as we speak :)

On the other hand, in your second snippet, it’s not clear where this settings object comes from. And I can’t follow the uses of the object. If I start at the construction of the settings object, I immediately run into “it’s stored into a singleton, which is… just there. At some point, someone might call getInstance on it, but I don’t know who does that, or when or why.

So I disagree with your analysis of dependencies.

On the other hand, it is certainly more convenient to just make the settings object globally accessible.

So go ahead and do that. But it doesn’t need to be a singleton to achieve that goal. Just a single global/static instance will allow everyone to access the settings object if they want to. There’s no need for messing around with singletons and all the other problems they cause.

Singletons are global, but globals are not singletons. If you need a global, that doesn’t mean you have to use a singleton.

SettingsClass.getSetting(‘showTooltips’)

Or you have it be an instance var on the Application class which is referenced by an instance var on the Controller class which is referenced by an instance var on the view and so on… You end up with the following:

self.parentController.parentApplication.settings.getSetting(‘showTooltips’);

Which is a (very!) hidden dependency. Or you do…

Application’s init: self.viewController.showTooltips = settings.getSettings(‘showTooltips’) viewController’s init: self.view = this.showTooltips

…and create tons of code with a multiplicity of by way of property names, making changes such as refactoring a serious sweat.

What I’m asking really, is what about the case for the singleton (or at least a global variable) where it reduces complexity for application areas which aren’t resource intensive?

Like many things in programming isn’t it a trade off between simplicity and covering all potential future cases?

The second part, about global access, is somewhat more subjective. Perhaps you really want global access to this object. In that case, go ahead and make it global. I think global access is nearly always the wrong thing, but it really doesn’t matter. If you want global access, use a global. If you don’t want global access, don’t make it a global. Neither case requires a singleton.

I also think you can solve the prob­lem get­ting those depen­den­cies vis­i­ble. Don’t you think you can assign a sin­gle­ton instance to a mem­ber vari­able of a class that needs it

Sure, you can do that. But then (1) why does it need to be a singleton, why does it need to be globally accessible, and (2) you still have no way to ensure that it’s never used in the “other” way. That’s what’s icky about singletons. You don’t know if these hidden dependencies exist. They might all be made explicit as you expect, but there might also be a number of“hidden” uses scattered around your code. You don’t know.

IMHO, I think it is not a bad idea to use Singletons in order to avoid having multiple instances of an object (i.e. the Model) and have a global access to the single instance.

I agree with you about the fact that Singletons increase hidden dependencies. But I also think you can solve the problem getting those dependencies visible. Don’t you think you can assign a singleton instance to a member variable of a class that needs it?

Doing so, you make the dependency visible and give yourself the opportunity to remove the single instance constraint if you made a bad assumption about it.

Does it make sense? Do I have to apologize for my english? :)

Of course, that doesn’t prevent someone using another instance, but if the application is architected that way, you can’t get the other code to use the instance you created even if you wanted it to.

BTW, it might not be a bad idea to write a bit about dependency injection to add to your singleton rants, since that’s in many ways a “do this where your current instinct is a singleton, and you get all these advantages”.

Anyway– I see Singletons as additional complexity on top of the overwhelming complexity that mutable global state itself brings. I don’t want that mutable global state in the first place, so Singletons bring no value to me, personally.

I don’t think ignorance of the codebase is a fruitful argument, one way or the other; people will do whatever they want to do, and sometimes people screw up. The best way to code (IMO) is such that screw ups are shown quickly and obviously. Globals tend to make this more difficult, as well.

The most useful statement made, I must say, is that of artificially constraining your objects. What’s the problem if someone instantiates another instance of this class? (and if they do it wrong, report the error promptly and unambiguously!)

I like to assume that people using my code are competent. I’m not naive enough to actually believe it to be the case, but incompetent developers will manage to break the code no matter what I do, so why bother with them?

But what situations can you imagine where the library developer might know that only one instance makes sense, but where the library user would nevertheless instantiate multiple objects?

Usually, the “you only need one instance” information is conveyed easily through simple naming and/or documentation. If I know that an object is responsible for, say, rendering all objects in my scene graph, then it is pretty intuitive that another instance won’t have access to the same scene graph, and so won’t be very useful. As a library user, I know intuitively that this one object is all I need, because it is associated with the data I want it to be associated with.

Or take the std::cout example from my post above. You’re right, a sufficiently dumb library user could instantiate another std::ostream when he intended to write to the standard output, but in reality, it just doesn’t happen, because real-world users of the standard library know that std::cout is the standard output stream, and they know they only need that one instance.

Can you think of a situation where the library user might mistakenly believe that creating multiple instances is warranted? I can’t. I won’t rule out that such situations exist, but in the common cases (see std::cout) it isn’t an issue.

It’s not that I assume programmers in general are smart enough to figure out how to use my library. It’s just that those who aren’t will manage to break it no matter what I do. Sure, I could sprinkle singletons all over it, but that still wouldn’t save them from themselves. There are still hundreds of ways in which they could break my library: passing invalid parameters to functions, freeing resources allocated by the library and so on.

Of course, a final point is that you’re not arguing for a singleton. You’re arguing for a “class-that-enforces-that-exactly-one-instance-will-exist”. That’s only half of the singleton. The singleton also provides global access. If you really think that enforcing the 1-instance-limit is best, then do that, but how does that excuse making the same object globally accessible?