2

I've been developing a game with my company for a good few years now. However recently we have been improving the base systems of our game to make future additions easier. One change we did was add Resource Managers instead of manually loading in information inside our Screen classes which are essentially game states. We decided to implement this as a singleton. I however am aware of the controversy in the use of singletons in the programming community. I will give an example of how we use our Font Manager down bellow. And I would like to know whether in this case a singleton is acceptable or whether you would recommend some other method.

mTextToBeDrawn.setFont(FontManager::GetInstance()->GetFont("Default"));

I am open to all suggestion and I will explain the current OOP design in order for a deeper understanding of the system. Every Manager extends from a base class called Manager with generic Add and Remove Methods. The Add and Remove Methods are then implemented in the derived classes. These classes only require one instance ever as the game will only require one State Manager, Font Manager and so forth. So should I use singletons or should I use another method in order to create better code.

user2437820
  • 63
  • 8
  • 1
    This looks awfully subjective. Do you have any problems with this approach, or are your concerns based on singletons bad reputation? – Captain Giraffe Nov 22 '15 at 21:33
  • I personally understand the problems of singletons I'm well aware of peoples opinions. This however doesn't matter as much. I'm just wondering if there is a better way or if singletons in the case are the best solution. – user2437820 Nov 22 '15 at 21:39
  • One of the potential gotchas about singletons beyond the obvious ones is that they're globals which are created and destroyed in a rather unpredictable order. That part isn't so bad if you just have one or two, it can become very bad if you have dozens that potentially depend on each other (where destroying one singleton might try to access another that was already destroyed, e.g.). So it helps to consolidate and maybe have a single singleton for the whole application, since that can aggregate all these "managers" and create/destroy them in a well-defined order. –  Nov 23 '15 at 00:01
  • Also with that kind of "consolidated application singleton" where you just have this one singleton for the entire application, if you ever change your mind and decide it should be instantiated more than once, that's a lot easier to manage than a boatload of singletons (still painful and involves cascading interface changes if you change your mind here, but not as hard to update the functions involve to pass along this one application object). –  Nov 23 '15 at 00:04

1 Answers1

3

Often in the programming community we hear "using X is bad" or "using X is good", but just labeling something as bad or good doesn't at all explain its' strengths and weaknesses or how something might be problem or how it could be used appropriately. If you don't understand why something might be bad, chances are you won't notice it when it creeps up in other forms or with different names.

In your example of the singleton, I would do a little research to identify criticisms and pitfalls of using of singletons and evaluate whether they will be a problem for you.

The biggest two concerns for me are:

  1. Singletons introduce global data and global state.

    With global data, access and modification can happen all over the code which makes bugs difficult to track down, and it can more easily get in messed up states. Often singletons are a result of poor design.

  2. Singletons are often not thread safe.

In some applications the pitfalls don't really become a problem. In the Cocoa/Objective-C world Apple occasionally uses Singletons to solve problems which are, in my opinion, completely fit for the job. Some of their usages are similar to what you describe such as image management/caching.

You can read more here What is so bad about singletons?

Community
  • 1
  • 1
Justin Meiners
  • 9,345
  • 6
  • 44
  • 90