I seem to keep reading it's a bad idea to use XxxManager style classes in game engine programming, yet even when I try to avoid their use I always end up with something that holds all the actors/entities/game world locations and acts upon them, which ends up being a Manager if by another name.

Is this really a bad pattern to follow? If so, what are the alternatives?

  • 2
    \$\begingroup\$ What's wrong with Managers? \$\endgroup\$ – Chris McFarland Jun 11 '16 at 7:34
  • \$\begingroup\$ blog.codinghorror.com/i-shall-call-it-somethingmanager and others, though I'm not so sure it really applies \$\endgroup\$ – Ross Taylor-Turner Jun 11 '16 at 8:17
  • 2
    \$\begingroup\$ That link doesn't really apply, it's about naming. I feel like this question might be a better fit for Programmers SE. \$\endgroup\$ – Tyyppi_77 Jun 11 '16 at 8:21
  • 3
    \$\begingroup\$ Actually, our friends at Programmers SE have already answered this question, take a look at this and this and this. Credit goes to a Google-search with "how to avoid manager classes programmers.se". \$\endgroup\$ – Tyyppi_77 Jun 11 '16 at 8:51
  • \$\begingroup\$ @Tyyppi_77 Choice quote from your StackOverflow link: "Don't get naming paralysis. Yes, names are very important but they're not important enough to waste huge amounts of time on. If you can't think up a good name in 10 minutes, move on." I agree. The code has to go somewhere. Call it however you please. \$\endgroup\$ – Chris McFarland Jun 11 '16 at 9:10

"Manager" classes can be problematic for various reasons. The two key reasons tend to be:

  • the name is unclear (what actually does "management" entail, and is it always the same for every type of thing being managed?)
  • they tend towards being buckets of functionality that violate the single responsibility principle (that is, that a type should do one thing)

Often one of those reasons causes or implies the other.

Those issues are good things to keep in mind, but don't them let paralyze your ability to actually make your game. In the end nobody is going to care what your classes are called or what they do. They're going to care about your game.

It's usually pretty easy to separate most "managers" into two parts:

  • the part that stores the actual objects and provides access to them (which you can call a "store," a "repository," a "database," a "cache," or various other things. This is the type that is usually responsible for the lifetime of the objects; that is, when an object is removed from or otherwise no longer contained by an instance of this type it ceases to exist.

  • the part that processes the actual objects and performs some work on them. It might update those objects (then it's an "updater" or "simulation") or it might draw them (then it's a "drawer" or "renderer"). Or it might do something else with them; the important thing is to name it according to its primary purpose. You'd generally give instances of this type a instance of or reference to instances of the first type (the one that just handles lifetime of the objects).

A reasonable argument could be made that the name of the first type could include manager (as it "manages the lifetime of" some objects). The world will not end if you name your type thusly, although you may need to put up with knee-jerk reactions of the form "don't call things managers" rather often, so you may want to avoid it just for that.

| improve this answer | |

When you read the blog post you linked to in the comments, then you will see that "being a Manager if by another name" is exactly what it wants you do to. It's general consensus in software development that global variables are evil, and the only alternative is that any data is held by other data.

The problem with a class named FoobarManager is that the word "Manager" doesn't tell you what the class actually does. For example:

  • When it controls the game mechanics of the foobars, you can name it FoobarController.
  • When it instantiates foobars but then delegates control to something else, it's a FoobarFactory or FoobarBuilder.
  • When it draws the foobars to the screen, it's a FoobarRenderer.
  • When it listens to events generated by foobars, it's a FoobarEventHandler.
  • When it waits for something to happen with the foobars, it's a FoobarObserver.
  • When it's just a dumb data holder for a collection of foobars without any logic at all, you just name it Foobars.

You could name any of these classes "Manager". But then it could perform any of these functionalities. And when you later realize that you need another of the above functionalities, you will also integrate that into the FoobarManager. So you will end up with a God Object which breaks the Separation of Concerns principle (every class should do exactly one thing).

| improve this answer | |
  • 1
    \$\begingroup\$ I often prefer to use the names FoobarStore or FoobarRepository to be even clearer about what it is for. \$\endgroup\$ – Lukazoid Jun 11 '16 at 11:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.