• Advertisement
Sign in to follow this  

The Singleton Pattern: To be or not to be [used]?

This topic is 1895 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm aware of the numerous problems that can arise through the use of the Singleton pattern, which some go as far as calling an anti-pattern... One of the biggest problems is all the references to the global instance/state, for example:

[source lang="csharp"]
// inside method body...
var obj = Something.Get();

obj.TakeAction();
obj.Whatever();
[/source]

This can really complicate testing and make code that's difficult to maintain...

However, I'm wondering if the Singleton pattern is not ok (or even optimal) for certain circumstances when only one, globally accessible instance of something should exist...

Consider the class I'm currently working on. It is called "NativeMemoryManager", and it is essentially a "safe" API for allocating, manipulating and releasing unmanaged process memory within a .NET application (it uses a 1:1 wrapper I wrote of the CRT memory management API as its back-end -- this is all part of my generalized application & game development framework). NativeMemoryManager inherits "DisposableObject", which is an abstract class that offers a robust implementation of the IDisposable interface; all instances of which are pushed into the "ObjectTable" which is traversed at application shutdown to destroy potential memory leaks...

Only one instance of NativeMemoryManager should ever exist. It's only field is a data table which stores critical information about all memory allocations to prevent memory errors and free any unfreed memory when the application is shutdown. It doesn't need multiple states, and I don't foresee myself ever wanting to replace the singleton instance with some sort of testing instance. Also, if I implement any objects which need to use/consume NativeMemoryManager I will make that object accept the instance in its constructor and store it locally:

[source lang="csharp"]
public SomeType( NativeMemoryManager mem )
{
this.nativeMem = mem;
}
[/source]

Then it will use the reference its stores rather than calling NativeMemoryManager.Obtain() over and over...

So considering this particular case and others like it, do you see any problem with using the Singleton pattern? Or is there a better way to approach this?

Share this post


Link to post
Share on other sites
Advertisement
+1 for Hodgman and swiftcoder answering what I would've said.

Add to that static initialization issues that will come as static fields/members try to use the memory manager to initialize themselves. Certainly uncommon, but a gotcha that will exist for any singleton implementation.

Share this post


Link to post
Share on other sites

...an implementation that expects to be the only instance...


I love this choice of phrase and it really highlights a key problem so effectively. You've identified a key failing in this design pattern - a huge dependency on factors outside of it's implementation. I'd +10 if I could.

Share this post


Link to post
Share on other sites
I don't understand how you can completely avoid globals? I completely understand to avoid it as much as absolutely possible, but for instance a logger object. Should you really pass your logger instance to all objects in your game that might need logging? And also say for example you use a framework like GLFW for input, how would you pass on the callback without storing some info globally? Edited by KaiserJohan

Share this post


Link to post
Share on other sites

Should you really pass your logger instance to all objects in your game that might need logging?


Yes.

Making it global is a time saving measure, that you can usually get away with if you're reasonably certain that the downsides (lack of testability, lack of flexibility, dependency issues, threading issues) aren't such a big deal. Even then, it's not what you should do and a singleton should never enter the conversation.

Share this post


Link to post
Share on other sites
I am repeating for the sake of reinforcing what has already been said.

I haven’t actually yet made an entirely non-global project, but I fully acknowledge that not only is such a project possible, it is actually desirable.
I almost wish the C++ language prohibited globals so that I would not have had any ability to have made such design decisions in my engine.

There is really no exception to the rule that any globals you have indicate a design problem.


I am not really answering your question regarding how it is possible to avoid globals, but:
#1: Unless you ask specifics, no one can answer that.
#2: The point is no matter what you think, there is a way. Of course to learn that way you will need to refer back to #1, and ask the appropriate question(s).


L. Spiro

Share this post


Link to post
Share on other sites
I think the real issue about singletons are global scope for types, not global scope for instances of these types. If you have a type that is global, which must not be instanced more than once (or zero), then you have a problem. That is, someone else can, by mistake or misunderstanding, instantiate too many of them. That is what the singleton pattern will prevent.

That said, the singleton pattern isn't the only solution, and usually not the best. It is easy to understand and use, and the lazy way out. Another solution would be to not make the type global. And one solution, as mentioned above, is to actually redesign the type so that it allows multiple instantiations anyway.

Share this post


Link to post
Share on other sites

If you have a type that is global, which must not be instanced more than once (or zero), then you have a problem


There is literally no problem that requires 'you must have only one or things blow up'. There are only broken designs that require such limitation.

Share this post


Link to post
Share on other sites

I don't understand how you can completely avoid globals? I completely understand to avoid it as much as absolutely possible, but for instance a logger object. Should you really pass your logger instance to all objects in your game that might need logging? And also say for example you use a framework like GLFW for input, how would you pass on the callback without storing some info globally?

Remember that not everything has to be an object. Turning everything into an object can be very poor object-oriented design, in fact. Logging facilities are something that can be implemented perfectly well without resorting to some kind of "logger object" should you so choose.

But if you choose to build that API as an object or set of objects, then passing those objects to interfaces that require them is a perfectly valid solution and generally more desirable than making those objects global if for no other reason than it makes the dependency on the logging system explicit.

A typical argument for why singletons/globals are good or necessary is along the lines of your initial query: "without global access, I will need to pass this object to every function." The flaw in that argument is that it exists because of a deeper implementation issue: every function is coupled to that object.

Share this post


Link to post
Share on other sites
i've yet to see a place where creating a singleton made sense to me, and "just using one instance" wasn't better.

it might be an issue on how to think about problems, but for me, it never ever made sense.

now i do understand why apis sometimes use the single global-to-you access-point, but even that does not need to be a singleton behind the scenes (it might be once-only for your app, but multiple times existing, say, in the os).

Share this post


Link to post
Share on other sites
The "there can only be one" approach is more than a little weird also from a modelling perspective. Object systems are typically designed to model real-world requirements: can you think of anything in the real world of which only one can ever exist?

Instances are unique (for example, all humans are subtly different from each other), but classes are never representative of only a single object (there can only be one sheep?).

Even things that we think of as solitary instances typically are not - the statue of liberty is treated as unique, but there is another one in France, and half a million small ones in gift shops.

Share this post


Link to post
Share on other sites
Sometimes, when you do top-down systems engeering using a language like UML to describe the software, singletons pop out when an association between objects is found to have a multiplicity of exactly one (1) in either direction.
https://en.wikipedia...i/Class_diagram

This means that, during run-time, the software itself would NEVER want to destroy or re-allocate this single object instance. Using the singleton pattern for the implementation ensures (through encapsulation of the "instance pointer" or whatever) that it is not possible to destroy/re-allocate the object instance during runtime.

Share this post


Link to post
Share on other sites

This means that, during run-time, the software itself would NEVER want to destroy or re-allocate this single object instance.


No, it means that there's a 1 multiplicity of the object (in relation to others). That you're only referencing one object. It sometimes means that you only have one object.

It does not mean that your software cannot (and will never) deal with two.

Share this post


Link to post
Share on other sites
<p><p>

[quote name='trasseltass' timestamp='1352397571' post='4998948']
This means that, during run-time, the software itself would NEVER want to destroy or re-allocate this single object instance.


No, it means that there's a 1 multiplicity of the object (in relation to others). That you're only referencing one object. It sometimes means that you only have one object.

It does not mean that your software cannot (and will never) deal with two.
[/quote]

Sorry, I do not follow at all.

"The UML representation of an association is a line with an optional arrowhead indicating the role of the object(s) in the relationship, and an optional notation at each end indicating the multiplicity of instances of that entity (the number of objects that participate in the association)."

If a car has one (1) steering wheel it does not mean that the car has an arbritary number of steering wheels, or that it sometimes has one steering wheel - it always has one steering wheel. If the produced car would have no steering wheels or 5 steering wheels, then it would probably not be the car that we were designing in the first place.

I'm not saying that the singleton pattern is for everyone, just that it solves the design problem of encapsulating a single object instance.

Share this post


Link to post
Share on other sites
Lots of good points made here against singleton, the way it should be. If the singleton's singleness is mere convenience, you're doing it wrong.

IMO there's only one "rule of thumb" you need to know: Everything that can be implemented without the singleton pattern, should be implemented without the singleton pattern.

Share this post


Link to post
Share on other sites

If a car has one (1) steering wheel it does not mean that the car has an arbritary number of steering wheels, or that it sometimes has one steering wheel - it always has one steering wheel.


Exactly. It does not mean there is only one steering wheel in the entire universe, which is what a singleton enforces.

Share this post


Link to post
Share on other sites

[quote name='trasseltass' timestamp='1352400093' post='4998968']
If a car has one (1) steering wheel it does not mean that the car has an arbritary number of steering wheels, or that it sometimes has one steering wheel - it always has one steering wheel.


Exactly. It does not mean there is only one steering wheel in the entire universe, which is what a singleton enforces.
[/quote]

If you are designing a universe I could see how that would be true. If your "system of interest" is a bit smaller, for example a car, it perhaps only exists one steering wheel.

Share this post


Link to post
Share on other sites

If a car has one (1) steering wheel it does not mean that the car has an arbritary number of steering wheels, or that it sometimes has one steering wheel - it always has one steering wheel.

But how many cars are there? For there to only ever be one steering wheel, there would also have to only ever be one car.

Your UML scenario indicates that there may be many-to-1 relations between objects. It in no way implies that there may ever be absolute many-to-1 relations.

I'm not saying that the singleton pattern is for everyone, just that it solves the design problem of encapsulating a single object instance.[/quote]
The "design problem of encapsulating a single object instance" is exactly that, a design problem.

Share this post


Link to post
Share on other sites

IMO there's only one "rule of thumb" you need to know: Everything that can be implemented without the singleton pattern, should be implemented without the singleton pattern.


I can think of four reasons where this may not hold true. I don't say that the following 4 cases always are true, just that there are situations where they are true.

  1. Doing an implementation for a thing that there must be only one of in such a way that the design allows for multiple future extensions takes more effort. Usually you have a limited budget, and the singleton pattern is very quick and easy to implement. The designer of the code maybe just isn't experienced enough, and as a project leader you sometimes have to accept something that works, even if it is not optimal.
  2. Testing the general purpose variant of the design may take more effort. (Yes, I know, using global instances of a singleton may also add to the testing effort, but the discussion about singletons is not the misuse of global objects).
  3. A generalized class can cost more CPU time. I am not saying it will, or that it really matters, just that it may be the case.
  4. The factory pattern is based on the singleton pattern. That is, it usually uses classes with a private constructor to force clients to use the factory methods.

Share this post


Link to post
Share on other sites
> But how many cars are there? For there to only ever be one steering wheel, there would also have to only ever be one car.

Sorry, I forgot to mention that the system of interest in this example is the car. We're designing a single car and eventually the goal is to deliver instances of this car, maybe in larger numbers. We're not designing and delivering a composite of multiple cars. smile.png Edited by trasseltass

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement