Take the 2-minute tour ×

Lately I've begun to think that having lots of manager classes in your design is a bad thing. The idea hasn't matured enough for me to make a compelling argument, but here's a few general points:

  • I found it's a lot harder for me to understand systems that rely heavily on "managers". This is because, in addition to the actual program components, you also have to understand how and why the manager is used.

  • Managers, a lot of the time, seem to be used to alleviate a problem with the design, like when the programmer couldn't find a way to make the program Just WorkTM and had to rely on manager classes to make everything operate correctly.

Of course, mangers can be good. An obvious example is an EventManager, one of my all time favorite constructs. :P My point is that managers seem to be overused a lot of the time, and for no good reason other than mask a problem with the program architecture.

Are manager classes really a sign of bad architecture?

share|improve this question
I think Of course, mangers can be good. An obvious example is an EventManager explains it all right there. A misuse of the concept is bad architecture, but there are legitimate use cases. The same holds true for most anything. –  Glenn Nelson Jan 11 '12 at 12:18
Seems more likely to be a sign of unimaginative naming. –  pdr Jan 11 '12 at 12:20
EventManager is a horrible name for a class. It ostensibly does something with events, but what? –  Christoffer Hammarström Jan 11 '12 at 15:26
one of the problems here is a language limitation steve-yegge.blogspot.com/2006/03/… Manager classes are often due to nounifying verbs, free functions are what is really wanted –  jk. Jan 11 '12 at 16:48
@jk Yes, that "Kingdom of Nouns" post is an epic, I remember reading it back when it first came out. –  Mike Nakis Jan 11 '12 at 19:12
add comment

8 Answers

up vote 13 down vote accepted

Manager classes can be a sign of a bad architecture, for a few reasons:

  • Meaningless Identifiers

    The name FooManager says nothing about what the class actually does, except that it somehow involves Foo instances. Giving the class a more meaningful name elucidates its true purpose, which will likely lead to refactoring.

  • Fractional Responsibilities

    According to the single responsibility principle, each code unit should serve exactly one purpose. With a manager, you may be artificially dividing that responsibility.

    Consider a ResourceManager that coordinates lifetimes of, and access to, Resource instances. An application has a single ResourceManager through which it acquires Resource instances. In this case there is no real reason why the function of a ResourceManager instance cannot be served by static methods in the Resource class.

  • Unstructured Abstraction

    Often a manager is introduced to abstract away underlying problems with the objects it manages. This is why managers lend themselves to abuse as band-aids for poorly designed systems. Abstraction is a good way to simplify a complex system, but the name “manager” offers no clue as to the structure of the abstraction it represents. Is it really a factory, or a proxy, or something else?

Of course, managers can be used for more than just evil, for the same reasons. An EventManager—which is really a Dispatcher—queues events from sources and dispatches them to interested targets. In this case it makes sense to separate out the responsibility of receiving and sending events, because an individual Event is just a message with no notion of provenance or destination.

We write a Dispatcher of Event instances for essentially the same reason we write a GarbageCollector or a Factory:

A manager knows what its payload shouldn’t need to know.

That, I think, is the best justification there is for creating a managerlike class. When you have some “payload” object that behaves like a value, it should be as stupid as possible so that the overall system remains flexible. To provide meaning to individual instances, you create a manager that coordinates those instances in a meaningful way. In any other situation, managers are unnecessary.

share|improve this answer
I have definitely created FooManager classes before. I've also created factories and proxies. But it seems sometimes what you really need is a GlorifiedCollection<Foo> type and FooManager seems to fit the bill perfectly. What would you call a class that literally manages the internal collection of Foo objects and provides very clean and concise interface for retrieving Foo instances? I guess to me a "manager" is a class that encapsulated a factory (i.e. all Foo instances are init'ed internally) as well as a collection of those objects. Would you call it something else? Or do different design? –  DXM Jan 12 '12 at 2:27
Ah yes, EventDispatcher, I've been trying to find a good name for a while now. :P –  Paul Jan 12 '12 at 14:38
add comment

Managers can be a sign of a bad architecture, but more often than not they are just a sign of an inability on behalf of the designer to come up with better names for his objects, or simply just a reflection of the fact that the English language (and any human language for that matter) is suitable for communicating every-day practical concepts, and not highly abstract, highly technical concepts.

A simple example to illustrate my point: before the Factory Pattern was named, people were using it, but they did not know how to call it. So, someone who had to write a factory for his Foo class may have called it FooAllocationManager. That's not bad design, that's just lack of imagination.

And then someone needs to implement a class which maintains lots of factories and hands them out to various objects that ask for them; and he calls his class FactoryManager because the word Industry just never occurred to him, or he thought it would be uncool because he never before heard of something like that in programming. Again, a case of lack of imagination.

share|improve this answer
add comment

Short answer: it depends.

There are several distinct forms of "manager classes", some of them are good, some others are bad, and for most of them it depends a lot on the context if introducing a manager class is the right thing. A good starting point for getting them right is to follow the single responsibility principle - if you know exactly what each of your manager class is responsible for (and what not), you will have much less problems understanding them.

Or to answer your question directly: it is not the number of manager classes indicating a bad architecture, but having too many of them with unclear responsibilities, or dealing with too many concerns.

share|improve this answer
add comment

Having lots of "manager" classes is often a sympton of an anemic domain model, where the domain logic is hoisted out of the domain model and instead placed in manager classes, which more or less equate to transaction scripts. The danger here is that you're basically reverting to procedural programming - that in itself may or may not be a good thing depending on your project - but the fact that it wasn't considered or intended is the real problem imo.

Following the principle of the "information expert", a logical operation should reside as close to the data it requires as possible. This would mean moving domain logic back into the domain model, so that it's these logical operations which have an observable effect on the state of the domain model, rather than 'managers' changing the state of the domain model from the outside.

share|improve this answer
add comment

While it might be easy to say that they are inherently indicative of a bad design, they can serve to bring a lot of good and reduce code complexity and other boilerplate code throughout the project by encompassing a single task and responsibility universally.

While the prevalence of Managers may be because of poor judgement on design, they may also be to handle the poor design decisions or incompatibility issues with other components in a componentized design or third-party UI components, or third-party webservices with a strange interface as examples.

These examples demonstrate where they are terribly useful for certain situations in reducing overall complexity and promoting loose coupling between various components and layers by encapsulating the "ugly code" in single place. One gotcha though would be that people find it tempting to make Managers as singletons, I would advise against this, and of course as others have suggested Single Responsibility Principle should always be followed.

share|improve this answer
add comment

Can manager classes be a sign of bad architecture?

You answered your question : they do not have to be a sign of a bad design.

Except for the example in your question with the EventManager, there is another example : in the MVC design pattern, the presenter can be seen as a manager for the model/view classes.

However, if you misuse a concept, then it is a sign of a bad design and possibly architecture.

share|improve this answer
In the question body - "having lots of manager classes in your design is a bad thing". I believe this is what the OP really wants to know. –  Oded Jan 11 '12 at 12:14
add comment

When the class has "Manager" in the name, beware of the god class problem (one with too many responsibilities). If it is difficult to describe what a class is responsible for with its name, that is a design warning sign.

Bad manager classes aside, the worst name I've ever seen was "DataContainerAdapter"

"Data" should be another one of those banned substrings in names- it's all data, "data" doesn't tell you very much in most domains.

share|improve this answer
add comment

Correct answer to this question is:

  1. It depends.

Every situation you'll encounter while writing the software is different. Maybe you're in a team where everyone knows how manager classes work internally? It would be completely crazy to not use that design. Or if you're trying to push manager-design to other people, in which case it might be bad idea. But it depends on exact details.

share|improve this answer
add comment

Your Answer


