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. đ 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?
Best Answer
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 involvesFoo
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 singleResourceManager
through which it acquiresResource
instances. In this case there is no real reason why the function of aResourceManager
instance cannot be served by static methods in theResource
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 aDispatcher
â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 individualEvent
is just a message with no notion of provenance or destination.We write a
Dispatcher
ofEvent
instances for essentially the same reason we write aGarbageCollector
or aFactory
: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.