Ogre Forums

All bullshit aside, correct me if I'm wrong, but basically in a one man project in which you KNOW you will be the only programmer to ever work on it, a Singleton offers no advantage what-so-ever offer a stantard extern/global variable, as the sole purpose of a Singleton is to enforce one instance of a certin class, to be used across multiple code files.

Right? Wrong? Anything to add?

Hi

Well just today I was thinking about this very same subject!

Disclaimer: I'm not an experienced programmer, but I try to carefully weigh the theoretical aspects of programming (read, think and plan much before coding anything).

This little rant of mine is about Engineers and other technologically orientated people in general, not just software developers: people get blinded by some stupid details and don't see the whole picture. I think that denying usage of global variables in every case everywhere is just that, blinded by a detail. This is what many technologically orientated people do often, and much. It's not just about programming, just take a look at your average Linux geek and see how much he pitys the fools who uses Windows OS. Blinded by details again and not seeing the whole picture. I am a Linux user myself by the way but I acknowledge that Linux is not good for every task, and it's not that secure as some people seem to claim.

Ah, that's it. My rant ends here.

I am also having a one man project and I am making my own design choices. It doesn't bother me much what and how others are doing their projects.

I'm going to disagree.

Mistakes happen. Say you get a new job, you work on the new job for 6 months, then come back to this project. You basically have to re-learn the project again, but somehow you forget that this variable is set once only. You have a problem with it not being set early enough, forget that there IS somewhere it's being set, and set it again.

Quite a few code rules are not just to ensure other devs don't step on your toes. They're safeguards to prevent our own mistakes as well.

A global variable doesn't allow you to instantiate the object only when required. It has to be there the whole time, and you can get into fun constructor ordering problems.

But on the whole I don't like singletons much any more. Instead, when I know that a class will definitely have only 1 instance, I sometimes don't use a class at all. I use a namespace with functions. Any state required is kept in an unnamed namespace in the cpp, so nothing can get to it, and the header doesn't polute other compilation units with unneeded info. The namespace acts like a singleton, but with less typing and no indirection.
Of course I then need explicit init and shutdown functions, but I don't mind that.

I'm with kojack on this one. Ever since I made similar considerations i've yet find a place where i really need a singleton. Usually there's no real need to have just one of a class, or it can be better handled at the module/namespace level.

Personally I don't think it's just a case of need - clearly there are a lot of ways you can implement the equivalent of a singleton.

However, let's think of Singleton as a pattern rather than an implementation. Everyone knows what it is, and why you generally use it. By implementing namespace level functions with state, you are actually implementing the Singleton pattern, just in a different way. So we're not actually arguing about the need for singletons (and they are needed sometimes), we're just arguing about the expression of them.

My argument is that by calling a class a Singleton explicitly, you're making that intention abundently clear and unambiguous, right there in the declaration of the class. Namespace level functions / state operate in the same way, but require extra comments to actually explain what they're for. That, in my opinion, makes a singleton class a good choice just from a point of view of immediate transparency.

And on the "basically in a one man project in which you KNOW you will be the only programmer to ever work on" comment - I'm afraid that's just naive. Pretty much every real project you ever work on will be:

a) used for longer than it was designed for
b) extended more times than it was ever intended to
c) have more people getting involved than you expect

And even if your current project is one of those that isn't, your next one problably will be - so it really doesn't pay to get into a habit of coding in a one-man-project style. I've had to educate 'lone star' programmers out of their bad habits before and in many ways it's harder to wean good lone coders off their bad habits than it is to train a new programmer good team-friendly habits from the off.

C++ gives us a choice. We can use a singleton or functions and variables enclosed in namespaces. But as for more modern languages that are firmly object-oriented like C# a programmer has no choice. And the only solution is using singletons. As for me I like a singleton pattern and use it widely in both C++ and C# to implement things like managers etc.

I just recently cut back on singletons. In projects that are meant for re-use singletons are another restriction on the user. My current project really needed multiple instances of managers, and so the singletons were removed. No singletons in the library at all now. But that is just way off topic.

Obviously the goal is to get a workable, good product finished. That is the end of any engineering effort. Sometimes people get lost in design, yes, and start to engineer the product for engineering's sake, but that's wrong. Having said that the programming overhead of implementing a singleton is tiny (for a basic singleton). So, why not? The benefits it offers over a global variable come at no extra cost. A singleton gives you all the benefits of a global variable, with fewer of the drawbacks, and little extra development time. While over-engineering is a problem, getting into the habit of programming well in general will help in the long-run.

The singleton design pattern is one design pattern among many. The spirit of those design patterns (as presented within the Design Patterns: Elements of reusable Object-Oriented Software book) is to provide a solution to a commonly encountered problem/situation (as well as a commonly used terminology).

At work I have to deal with old code (from the 80s) as well as new code. Over the years there have been many programmers, each with his/her approach to various problems. Let me tell you that I've seen some very innovative solutions, ranging from the perfectly obvious to the absolutely convoluted, bordering on the magical/voodoo.

So yes, we can reinvent solutions that all accomplish the same goal (in our topic, ensuring that there is a single instance of a class), or we can adopt one that has been tested, verified, and somewhat universally adopted (ok, I'm dreaming on that last one).