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?

My general gut feeling is that if you have one of something then there are always going to be cases where you may eventually need more than one, even if they're not immediately obvious.

Take your memory manager example - right now you only see the need for one, yes. But what if you decide to implement two memory pools, one of which is persistent for the entire application run, the other of which is used to manage memory for the current map you're running? It's incredibly convenient to just be able to throw away all memory for a map in one operation. Then you might decide that a third - for short-lived temp objects (typically a duration of one frame but may be even less) - is in order. And a fourth for temp storage while loading objects. And so on.

These are just examples off the top of my head and I'm not saying that they're all going to apply to your specific case, just illustrating the principle of "having one implies potential need for more than one".

Regarding the singleton pattern itself, I've felt for some time that it is symptomatic of an attempt to shoe-horn an OO design onto something that is not OO in nature more than anything else. Just personal opinion and I'm willing to be wrong on that one, but almost every implementation I've encountered has that hallmark.

If you're talking "objects" you are by definition talking "potentially more than one" so building that potential in from the start can save you lots of hassle later on.

N.B. a singleton is a glorified global (and globals are bad), so any usage (even correct usage) of the pattern is still evil.

for certain circumstances when only one, globally accessible instance of something should exist...

That's the trap -- people confuse "should" with "must".
Singleton is only valid when there "must" only be one instance and it would be invalid for there to possibly be more than one in any possible circumstance, ever... which is quite rare.

Your NativeMemoryManager case is one of those out-of-convenience, "I don't need 2+ right now" cases, where 2 doesn't seem useful, but isn't an error. Therefore using a singleton is possible (many do this), but it's an abuse of the pattern, and the reason it's an anti-pattern. If you write your code in such a way where 2+ instances will work, then the code will be more robust and reusable in the long term, while also still being useful in your short term only-one-instance case.

The most common way of doing this is to write NativeMemoryManager in the non-singleton style, and then create a single global instance of it.
In your case, you're planning on doing the right thing(tm) of passing the instance to other objects via their constructors, so you don't even need to make a global instance of it anyway...

Only one instance of NativeMemoryManager should ever exist.

So what happens when your application becomes multi-threaded? Are you going to wrap the NativeMemoryManager in a mutex, and thus serialise memory allocation/deallocation for all threads? Or are you going to allocate one NativeMemoryManager for each thread that needs to use native memory?

+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.

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:

The fact that your motivating example is particularly inappropriate, for already explained reasons, tells a lot about the pitfalls of the Singleton anti-pattern.

You actually want to use a singleton because your NativeMemoryManager has an implementation that expects to be the only instance, but it is actually a rather bad shortcut you shouldn't have taken; reserving different memory areas so that different instances of NativeMemoryManager don't step on each other's toes should be almost trivial, and you should define a suitable Allocator or UnmanagedMemoryAllocator interface allowing not only for test dummies and experimental implementations but also for decorators, composites, and other useful design patterns.

...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.

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.

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