Are people still using Singletons?

I think a lot of people use singletons as an excuse to do procedural programming and call it object-oriented programming. They've been sold the standard line about the superiority of "pure OOP" without anyone bothering to mention the caveats, and are looking for some way to do things in (to them) the natural way without breaking the OOP tenets.

In the increasingly rare cases where I roll up my sleeves and do almost-pure OOP, I use singletons only for very low-level system objects such as the garbage collector.

Singletons are global variables without the initialization order problem. Nothing more, nothing less.

Actually, a singleton can be more, as you can choose among several implementations when you first create it, using polymorphism (as opposed to compile-time implementation choice using a global variable).

OP: Global-scope variables do have a large interest because of their availability. Developers have to face a choice between developing an application quickly now and run the risk of having to do hard refactoring work later on through the use of global-scope variables, or to spend more time writing code without globals, which takes longer to write than global-using code as long as the variables are used as if they were globals, only to gain time later, when the variables won't behave like globals anymore.

Depending on the likeliness of having to develop more later on, it might be more efficient to use or not to use a singleton for a given thing.

I really love singletons, when it comes to manager classes or object factories. In my opinion that's the best solution for these two cases.

Quote:

Original post by petewood Personally I've never used one. They are an easily implementable pattern so people tend to use it without having the understanding of its consequences. See this article by industry veteran, Robert Martin: Singleton Vs Just Create One.

Ugh. Who wants to pass an object through several layers of objects who don't care? I'd use a static class or singleton before JCO...

I agree with hunta! I use singletons for the situations he mentioned.

I use singletons where they belong, in the very core objects, such as the memory manager, logger, and task manager. It seems to fit into my design well, so why not use it? Heaven knows what all would go wrong if you had two memory managers running in tandem...

I use singletons in Animadead for mesh and animation cachers. The idea is if the user tries to load a mesh or animation that's already loaded it should return the instance of the existing mesh or animation instead of creating a copy. Plus if the user has more than one model, it should use the same cachers for the different models. Passing each model an instance of the cachers on creation is unecessary and would complicate the interface to the library.

The problem with global variables (which singletons are) is that anything may depend on them. If you want to be sure some code works you have to check it with all possible combinations of global state.

As most of a program will depend on the memory manager it is quite reasonable to make it global.

i'm no fan of singletons how-ever

Quote:

Original post by Trap Singletons are global variables

Singletons are never mean't to replace global variables if your using them for that then your doing something seriously wrong, GOF definition is:

Quote:

Ensure a class has only one instance and provide a global point of access to it.

where does the description mention anything about global variables, sure it mentions:


and provide a global point of access to it.


that doesn't mean replace global variables.

Quote:

Original post by Trap without the initialization order problem

Yes they do and can suffer from it badly if not implementated correctly in a languages such as C++ (and if you want to see that have a look in the book "Modern C++ design: Generic programming & design patterns applied").

Confusing title, the article doesn't conclude by saying singletons should be avoided, like this topic title suggests.

My view on the article is that it makes no sense. 'Just Create One' is/can be the singleton pattern(assuming the instance has a global point of access), its like comparing like to like.

By telling your development team to only make one instance you are ensuring that there is only one instance.

Quote:

Original post by snk_kid Yes they do and can suffer from it badly if not implementated correctly in a languages such as C++ (and if you want to see that have a look in the book "Modern C++ design: Generic programming & design patterns applied").

Well, anything suffers problems if not implemented correctly. Whats your point?

Quote:

Original post by Jingo By telling your development team to only make one instance you are ensuring that there is only one instance.

If you have that luxury. I for one am developing a library, and you can't expect users to conform to 'DO NOT CREATE MORE THAN ONE INSTANCE OF THIS' in the manuals.

But I do agree with the article, in that many people overuse singletons. Simply put, my idea of when to use a singleton is:

A class that manages an entity of which there can either only be one, or of which you are absolutely sure you only need one.

Things like managers and factories can be good examples, but I can think of a number of cases where you'd want more than one of those.

Quote:

Original post by Trap Singletons are global variables without the initialization order problem. Nothing more, nothing less.

There are significant differences between a singleton and a global variable. Unlike a global variable, a singleton isn't simply data. A singleton should provide a public interface that regulates how the programmer interacts with it. Singletons thus provide some level of data hiding since a programmer will access it only through its public interface. One major problem with global variables is unrestricted, unprotected access - the singleton design pattern overcomes this since the coder interacts with it only through public functions.

I tend to use the singleton design pattern for lower-level managers and such. I have difficulty, for example, creating and passing around a settings-manager throughout a program since it needs to be accessed by multiple parts of the engine and there should be only one instance of it.

Quote:

Original post by andrewo Quote: Original post by Trap Singletons are global variables without the initialization order problem. Nothing more, nothing less. There are significant differences between a singleton and a global variable. Unlike a global variable, a singleton isn't simply data. A singleton should provide a public interface that regulates how the programmer interacts with it. Singletons thus provide some level of data hiding since a programmer will access it only through its public interface. One major problem with global variables is unrestricted, unprotected access - the singleton design pattern overcomes this since the coder interacts with it only through public functions. I tend to use the singleton design pattern for lower-level managers and such. I have difficulty, for example, creating and passing around a settings-manager throughout a program since it needs to be accessed by multiple parts of the engine and there should be only one instance of it.

I think what he means is that you could either create a singleton class, or create a global instance of that class, but the difference is that with a global variable (and that's where you do have a point) can be reassigned, and thus, reinitialized. A singleton can't.

Quote:

Original post by SirLuthor I use singletons where they belong, in the very core objects, such as the memory manager, logger, and task manager. It seems to fit into my design well, so why not use it? Heaven knows what all would go wrong if you had two memory managers running in tandem...

Exactly! the whole point about singletons is that they should be used whenever you want to enforce one and only one instance of an object, and should really only be used to model these kinds of objects...The examples luthor gives are pretty good ones, memory manager, logger etc. I have seen renderers implemented as singletons, and yeah i suppose this is fine if your only going to have one renderer, but what if you want multiple viewports each with it's own unique renderer instance.

I think like the OP said it's important to understand the full implications of using them.

Quote:

Original post by Trap Singletons are global variables without the initialization order problem. Nothing more, nothing less

Actually depending on how you implement your singletons there are a whole raft of initialisation order problems, not only that, but destruction order problems, a problem which can be solved by using phoenix singletons.

This book has an amazing discussion on singletons

Quote:

Original post by Trap Quote: Original post by snk_kid Yes they do and can suffer from it badly if not implementated correctly in a languages such as C++ (and if you want to see that have a look in the book "Modern C++ design: Generic programming & design patterns applied"). Well, anything suffers problems if not implemented correctly. Whats your point?

Well my point is your giving out false information.

Quote:

Original post by andrewo I tend to use the singleton design pattern for lower-level managers and such. I have difficulty, for example, creating and passing around a settings-manager throughout a program since it needs to be accessed by multiple parts of the engine and there should be only one instance of it.

I'll respond to this quote but this equally applies to the many people who say the same thing.

If the only obvious alternative to you to having a Singleton (global variable) is to pass the object around throughout a program then you probably haven't separated your program into layers.

Also, it is possible that the singleton has been given too many responsibilities and the code using it doesn't actually make use of them. I'm not talking about what Robert Martin said about it having both the job of being a class and enforcing one instance and entry point. I'm talking about something else. For example, using your settings manager for instance, it is globally available so that your input devices, renderer, network device, etc, can all get the settings they need from it. Simple. But why does a keyboard need to know how the renderer is configured? Of course it doesn't need to know, but it has access to that information through the singleton. The point isn't that someone could abuse that, the point is that, if the keyboard doesn't need in any way to know about, or have access to the configuration information for the renderer, then it shouldn't.

If you split the configuration information up into separate information for the renderer, input device, etc, and only pass through what is needed by each layer, it will make your design modular and more easily testable.

People object to passing what would have been the singleton around because it would mean an extra parameter which might not be used. I think you should try it. You may find it's a lot less change than you thought.

[Edited by - petewood on February 18, 2005 3:22:22 PM]