How can I avoid having many singletons in my game architecture?

I initialize my services in my main application class and then pass them as pointers to whatever needs to use them either through the constructors or functions. This is useful for two reasons.

One, the order of initialization and cleanup is simple and clear. There is no way to accidentally initialize one service somewhere else like you can with a singleton.

Two, it's clear who depends on what. I can easily see what classes need what services just from the class declaration.

You may think it's annoying to pass all these objects around, but if the system is designed well, it's really not bad at all and makes things much clearer (for me anyway).

I won't discuss about the evilness behind singletons because Internet can do that better than me.

In my games I use the Service Locator pattern to avoid having tons of Singletons/Managers.

The concept is pretty simple. You only have one Singleton that acts like the only interface to reach what you used to use as Singleton. Instead of having several Singleton you now have only one.

Calls like :

FlyingToasterManager.GetInstance().Toast();
SmokeAlarmManager.GetInstance().Start();

Looks like this, using the Service Locator pattern:

SvcLocator.FlyingToaster.Toast();
SvcLocator.SmokeAlarm.Start();

As you can see every Singleton is contained in the Service Locator.

To have a more detailed explanation I suggest you to read this page about how to use the Locator Pattern.

[EDIT] : as pointed in comments, the site gameprogrammingpatterns.com also contains a very interesting section on Singleton.

I hope it helps.

Reading all these answers, comments and articles pointed out, especially these two brilliant articles,

• http://gameprogrammingpatterns.com/singleton.html
• http://gameprogrammingpatterns.com/service-locator.html

eventually, I have come to the following conclusion, which is kind of an answer to my own question. The best approach is not to be lazy and pass dependencies directly. This is explicit, testable, there is no global access, can indicate wrong design if you have to pass delegates very deep and in many places and so on. But in programming one size does not fit all. Thus, there are still cases that it is not handy to pass them directly. For example in case we create a game framework (a code template which will be re-used as a base code to develop different kinds of games), and include there lots of services. Here we don't know how deep each service can be passed, and how many places it will be necessary. It dependents on a particular game. So what do we do in this kind of cases? We use Service Locator design pattern instead of Singleton, which is actually the same Singleton, with the following very important improvements:

1. You don't program to the implementations but to the interfaces. This is very essential in terms of OOP principals. At runtime you can change or even disable the service using Null Object pattern. This is not only important in terms of flexibility, but it directly helps in testing. You can disable, mock, also you can use Decorator pattern, to add some logging and other functionality as well. This is very important property, which Singleton does not have.
2. Another huge advantage is that you can control the lifetime of the object. In Singleton you only control the time the object will be spawned by Lazy Initialization pattern. But once the object is spawned, it will live until the end of the program. But in some cases you would like to change the service. Or even shut it down. Especially in gaming this flexibility is very important.
3. It combines/wraps several Singletons into one compact API. I think you may also use some Facade like Service Locators, which for a single operation might use several services at once.
4. You may argue that we still have the global access which is the main design problem with the Singleton. I agree, but we will need this pattern only and only if we want some global access. We should not complain about global access, if we think that direct dependency injection is not handy for our situation, and we need a global access. But even for this problem, an improvement is available (see the second article above). You can make all the services private, and you can inherit from Service Locator class all the classes you think they should use the services. This can significantly narrow the access. And please consider that in case of Singleton you cannot use inheritance because of the private constructor.

Also we should consider that this pattern was used in Unity, LibGDX, XNA. This is not an advantage, but this is kind of a proof of the usability of the pattern. Consider that these engines were developed by lots of smart developers a long time and during the evolution phases of the engine they still didn't find any better solution.

In conclusion, I think Service Locator can be very useful for the scenarios described in my question, but still should be avoided if it is possible. As a rule of thumb - use it if you have to.

It isn't uncommon for parts of a code base to be considered cornerstone objects or a foundation class, but that doesn't justify it's life cycle to be dictated as a Singleton.

Programmers often rely on the Singleton pattern as a means of convenience and pure laziness rather than taking the alternate approach and being a tad more verbose and imposing object relationships between one another in an explicit manor.

So ask yourself which is easier to maintain.

If you're like me, I prefer to be able to open a header file and briefly skim over constructor arguments and public methods to see what dependencies an object requires rather than having to inspect hundreds of lines of code in an implementation file.

If you had made an object a Singleton and later realize you need to be capable of supporting multiple instances of said object, imagine the sweeping changes needed if this class was something you used pretty heavily throughout your code base. The better alternative is to make dependencies explicit, even if the object is only allocated once and if the need arises to support multiple instances, you can safely do so without such concerns.

As others have pointed out, use of the Singleton pattern also obfuscates coupling that often signifies poor design and high cohesion between modules. Such cohesion is usually undesirable and leads to brittle code that can be hard to maintain.

Singleton is a famous pattern, but it's good to know the purposes it serves, and its pros and cons.

It really makes sense if there is no relationship at all.
If you can handle your component with a totally different object (no strong dependency) and expect having the same behavior, the singleton may be a good choice.

On the other hand, if you need a small functionality, only used at certain times, you should prefer passing references.

As you mentioned, singletons have no lifetime control. But the advantage is they have a lazy initialization.
If you don't call that singleton in your application lifetime, it will not be instantiated. But I doubt you build singletons and not use them.

You must see a singleton like a service instead of a component.

Singletons works, they never broke any application. But their lacks (the four you've given) are reasons you won't make one.

Singletons to me are ALWAYS bad.

In my architecture I created a GameServices collection that the game class manages. I can search add to and remove from this collection as required.

By saying something is in global scope you are basically saying "this hting is god and has no master" in the examples you provide above I would say most of those are either helper classes or GameServices in which case the game would be responsible for them.

But that's just my design in my engine, your situation may be different.

Putting it more directly ... The only real singleton is the game as it owns every part of the code.

This is answer is based on the subjective nature of the question and is based purely on my opinion, it may not be correct for all developers out there.

Edit: As requested ...

Ok this is from my head as I don't have my code in front of me at the moment but essentially at the root of any game is the Game class which is truely a singleton ... it has to be!

So I added the following ...

class Game
{
   IList<GameService> Services;

   public T GetService<T>() where T : GameService
   {
       return Services.FirstOrDefatult(s => s is T);
   }
}

Now I also have a system class (static) that contains all my singletons from the entire program (contains very little, game and config options and thats about it) ...

public static class Sys
{
    // only the main game assembly can set this (done by the game ctor)
    // anything can get
    public static Game Game { get; internal set; }
}

And usage ...

From anywhere I can do something like

var tService = Sys.Game.getService<T>();
tService.Something();

This approach means that my game "Owns" stuff that would typically be considered a "singleton" and I can extend the base GameService class however I want. I have interfaces like IUpdateable that my game checks for and calls in to any services that implement it as needed for specific situations.

I also have services that inherit / extend other services for more specific scene scenarios.

For example ...

I have a Physics service that handles my physics simulations but depending on the scene physics simulation may need some slightly different behaviour.

An essential ingredient of singleton-elimination which opponents of singleton often fail to consider is adding extra logic to deal with the vastly more complicated state that objects encapsulate when singletons give way to instance values. Indeed, even defining the state of an object after replacing a singleton with an instance variable can be difficult, but programmers who replace singletons with instance variables should be prepared to deal with it.

Compare, for example, Java's HashMap with .NET's Dictionary. Both are quite similar, but they have a key difference: Java's HashMap is hard-coded to use equals and hashCode (it effectively uses a singleton comparator) while .NET's Dictionary can accept an instance of IEqualityComparer<T> as a constructor parameter. The run-time cost of keeping the IEqualityComparer is minimal, but the complexity that it introduces is not.

Because each Dictionary instance encapsulates an IEqualityComparer, its state is not just a mapping between the keys it actually contains and their associated values, but instead a mapping between the equivalence sets defined by the keys and the comparator and their associated values. If two instances d1 and d2 of Dictionary hold references to the same IEqualityComparer, it will be possible to produce a new instance d3 such that for any x, d3.ContainsKey(x) will equal d1.ContainsKey(x) || d2.ContainsKey(x). If, however, d1 and d2 may hold references to different arbitrary equality comparers, there will in general be no way to merge them so as to ensure that condition holds.

Adding instance variables in an effort to eliminate singletons, but failing to properly account for the possible new states that could be implied by those instance variables can create code which ends up being more brittle than it would have been with a singleton. If every object instance has a separate field, but things will malfunction badly unless they all identify the same object instance, then all the new fields have bought is an increased number of ways things can go wrong.