Can manager classes be a sign of bad architecture?

Question

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 Work^TM 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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

Manager classes -- just like almost any class ending with "-er" -- are evil and have nothing to do with OOP. So for me it's a sign of bad architecture.

Why? The "-er" name implies that a code designer took some action and converted it to class. As a result we have an artificial entity that doesn't reflect any tangible concept, but some action. This sounds very procedural.

Besides that, typically such classes take some data and operate upon it. This is a philosophy of passive data and active procedures and it found its place in procedural programming. If you realize that, there is nothing bad in Manager classes, but it's not OOP then.

Object-thinking implies that objects do things to themselves. Discover your domain, build semantic nets, let your objects be living organisms, smart and responsible humans.

Such objects don't need to be controlled. They know what to do and how to do. So Manager classes break OOP principles twice. Besides being an "-er" class, it controls other objects. But it depends on the manager though. It he controls -- he's a bad manager. If he coordinates -- he's a good manager. That's why a "C" letter in MVC should be spelled as "Coordinator".