You can suggest the use of Boost or std::unique_ptr and quite literally get a totally negative response coupled with “but what about speed?!” The game industry is so for-profit and so overly-pragmatic (if you can even call their practices practical) that they constantly harm themselves repeatedly before taking a step back and saying, “oh look, guys, everyone else solved this problem years ago!”

It’s stupid.

But yet I agree with the fact of creating useless objects like in the car example, people forget that objects are good for data encapsulation in a way that only the object has access to the raw data and provides functions to manipulate it.

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?

I agree that Connect has been somewhat of a joke for many years but I must say that since Doug took over as the PM for Feedback at MS, things have started to move (slowly, but still moving) in the right direction. There’s still a long way to go but I hope they will get there…

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? :)