Alternatives to Singletons [closed]

Question

This is related to: What is so bad about Singletons

Can you give me some examples where Singletons can be avoided using other techniques? I need to use this in C++ so you can give examples with C++ specific techniques.

To be more clear: How you would implement a file manager, resource manager, log manager, etc without singletons.

Answer 1

Simple: create a single instance of your file manager (or whatever) class, and then pass it around inside your application as necessary. Much will depend on your application structure, but typically you have some sort of controller object that creates the other important objects in the application. That might be the object to instantiate the file manager, and then pass it to the other objects it creates that need a file manager.

If you're using a singleton because there MUST be no more than one instance of a certain class, that's usually okay. If you're using it because a singleton is a globally-accessible object that lets you avoid thinking about how the other objects talk to each other and what each object is responsible for, that's where you start to run into problems.

The file manager is a nice example. At first it seems like there should only ever be zero or one instances of the file manager object. But is that necessary? Can't you have two file systems on one machine at the same time?

Answer 2

How you would implement a file manager, resource manager, log manager, etc without singletons.

By not making them singletons and passing them down the call-tree and object-nets as parameters and references instead.

As a general rule: If you only need n instances, then create just n instances.

Or: If two instances of a well-designed class do not clash without breaking the class' contract, do not make it a singleton.

Answer 3

Can you give me some examples where Singletons can be avoided using other techniques?

In higher level code, simply create the instance directly, and pass that around. You should be doing this at as high a level as possible that still makes sense.

In lower level code, accept a reference to an existing instance as a parameter. Don't accept a factory if you can avoid it without ham-stringing your design, and definitely don't call a constructor/new on things that aren't core to the logic of that class.

If you follow both these rules you'll implicitly manage the number of instances you create, and won't paint yourself into a corner by forcing a singleton design (that is often short-sighted to begin with).

How you would implement a file manager, resource manager, log manager, etc without singletons

I wouldn't. I'd create classes that could be instanced, and let the application itself call the shots on how many instances got created, and how they are created.

At the same time, I wouldn't let low level parts of my application call any shots. Just because I write to a log doesn't mean I have to know where it should be stored, what level of the logging hierarchy I'm writing to, what filters should be applied to it, etc.

I'd let the high level portions of my code decide these things. That way if I change my mind, I can scrap earlier decisions, blow away and recreate some top-level code, and not touch any of the code that writes to the log (the majority of my app).