74

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?

Thomas Owens
  • 82,739
Paul
  • 2,174
  • 3
  • 18
  • 18
  • 6
    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. –  Jan 11 '12 at 12:18
  • 33
    Seems more likely to be a sign of unimaginative naming. – pdr Jan 11 '12 at 12:20
  • 11
    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
  • 7
    one of the problems here is a language limitation http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html 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
  • 2
    Managers often have a lot of power (responsibilities) and they can be a pain to deal with - just like in any office environment ;) EventManager means nothing. EventDispatcher describes what it does. – CodeART May 08 '14 at 09:38
  • 1
    Just like in real life, having too many managers is not a good idea. For anything that is non-trivial, however, some are alright – tofro Feb 06 '17 at 10:44
  • Closely related: https://stackoverflow.com/questions/1866794/naming-classes-how-to-avoid-calling-everything-a-whatevermanager – Erel Segal-Halevi Jan 29 '20 at 08:57

9 Answers9

53

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.

Jon Purdy
  • 20,547
  • 3
    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 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 02: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
  • @DXM Just for a collection of Foos, it can literally be "FooList". For the global place where Foos are registered so they can be retrieved later, "FooRegistry", comes to mind. Combining collection & factory is not something I personally like to do, but i believe that that would usually be called a "FooRepository". – R. Schmitz Jul 10 '19 at 11:35
  • "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?" You call it a FooRepository. – Scott Hannen Dec 31 '19 at 19:59
37

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.

Mike Nakis
  • 32,193
  • 7
  • 77
  • 112
  • 2
    But bad naming may also leads to bad architecture. Because others may attache responsibilities to the badly named entity that is orthogonal to its goal and to the purpose of its creator. Also when others create new entities/interfaces they may be influenced by the names of the badly named entities. – adnanmuttaleb Feb 03 '20 at 07:50
  • @adnanmuttaleb sure. I don't disagree. – Mike Nakis Feb 03 '20 at 08:04
  • But then it still is a manager, just with name not ending -er. Class renaming from ending -er to something else does not make class different, just the name different. If managers are bad then factories are bad? And controllers are bad? – Darius.V Dec 15 '23 at 11:45
  • @Darius.V I do not assign much importance to the -er ending. It is neither good or bad. What it boils down to is that managers are usually invented in order to handle incidental complexity. If you are not to have any managers, then presumably your design will consist exclusively of domain-specific objects. Well, good luck building a hotel system that consists exclusively of rooms, beds, guests, and reservations. – Mike Nakis Dec 15 '23 at 14:58
  • You will need some additional objects to handle some of the nitty-gritty mechanics of the whole thing. My point is that whether you call them managers or something else depends on your naming skills. Ideally, you would give them names that correctly reflect what they are doing, inventing suitable names if necessary, instead of just calling them managers. – Mike Nakis Dec 15 '23 at 14:58
13

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.

MattDavey
  • 7,116
9

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.

Doc Brown
  • 206,877
  • Sorry, I don't see this answer as very useful. You make a good point that unclear responsibilities and too many concerns are bad. But that applies to any class, not just a "Manager" class. The other answers seem much more specific on how a manager class may be helpful or detrimental. – user949300 Nov 27 '17 at 19:33
  • please stop giving this wikipedia article about SRP, have read it many times, it does not clearly explain what is SRP. After many years since I first time read about SRP, I still do not understand it. If nobody can give clear explaination then this term I think maybe should not even be used. – Darius.V Dec 15 '23 at 11:47
  • @Darius.V: when I wrote this answer in 2012, the Wikipedia reference was my first choice in lack of something better. In between (in 2014) Bob Martin wrote his own, - arguably - clearer explanation (I changed the link right now). However, I guess you already know this blog post and may have the same issues with it. I can understand this, SRP is not a strictly defined CS term, and many people are somewhat disappointed that it is not, they have a different expectation about it. .... – Doc Brown Dec 15 '23 at 12:42
  • ... Personally, I think the SRP relies on the responsibility a software designer defines for a certain module. It is a thought model, a guideline to remind people they should try (and try harder!) to split code into sensible modules. The result, however, always depends a lot on the education and experience of the designer, ask 5 software designers to refactor some Big-Ball-Of-Mud according to the SRP, and you will get 5 different results. – Doc Brown Dec 15 '23 at 12:49
  • @DocBrown I have not seen this post but I have watched clean code videos in youtube. So I also think that people interpret it in different ways and then say use SRP but how can I use it if it is not clearly defined even if others do use it same way. Sounds like useless principle. Imo trying harder also can be waste of time. I prefer do by feeling when to split, and when not. Or even if you review, code just say split this this and this into separate classes. This will be at least clear what to do but not "use SRP" – Darius.V Dec 18 '23 at 11:07
  • Plus what is making me angry - that those who say use SRP think they are good and you are bad because you do not know. But if you know well, then you should be able to explain and define I think so that the listener having this information would never make it incorrectly. – Darius.V Dec 18 '23 at 11:12
  • @Darius.V: the SRP is not a cooking recipe, it is only a smooth guideline. But even that guideline isn't applied as often as it should when you see how much code with too-huge classes and functions is produced in the wild. However, I think you should not blame Bob Martin on your teammates misbehaviour, when they abuse the SRP for this. – Doc Brown Dec 18 '23 at 12:44
  • @DocBrown by Bob you mean this https://en.wikipedia.org/wiki/Robert_C._Martin ? If so when I use his information, it felt like he is not giving a guideline. He looked like in one place he is telling a statement, then in the other place he does not use his statement logic. I do not like that, it is not understandable content. Are there exams on this principle where you would have to refactor code to match this? I believe then there would be many unfair judgement. When I was studying informatics, there was no lectures about this principle. – Darius.V Dec 18 '23 at 13:00
  • @Darius.V: when I studied CS, the term SRP wasn't even born (but the references Bob Martin gave in his blog article were well known). I have no idea if there are universities on the world which teach this today, I am not omniscient. "Exams" sound you still struggle with your expecation - not every useful principle in software engineering is a hard-and-fast rule or recipe which can be applied in a braindead manner. – Doc Brown Dec 18 '23 at 13:17
3

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.

maple_shaft
  • 26,511
  • 11
  • 57
  • 132
3

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".

Vadim Samokhin
  • 2,186
  • You make an interesting point but I still wonder how would you categorize an "entity manager"? From my personal background, an manager is meant for CRUD operations on a particular . Does it lead the domain model to be anemic? I don't think so, just not "active record". Furthermore can't we put in an "entity manager" entity's aggregate compounds CRUD coordination logic? I don't see a better place for that. So this may be seen as a CRUD facade somehow also... – ClemC Dec 30 '17 at 17:49
  • All I can say about the concep of ORM is https://medium.com/@wrong.about/you-dont-need-an-orm-7ef83bd1b37d – Vadim Samokhin Dec 31 '17 at 11:04
  • I was not necessary referring to ORMs, however... I respect as much as I can OO principles but it seems to me like they're pretty much theoric and can't always be fully applied in practice... For example, if we need decoupling, reusability, DRY, productivity, eg: putting domain logic/rules that apply to different entities in common services, hence making the domain model less behavioral... That's the exact effect of a repository/mapper pattern (which ORM you refer to implement) VS an active record pattern which I believe you'd favor... – ClemC Jan 01 '18 at 00:12
  • Very strong claims, and I agree that it would've been awesome to see some examples of how "-er" classes could be turned into "proper OOP". Also, regarding what you are saying about "Coordinator", please remember that the "-or" suffix is just a variation of "-er", the choice of the vowel depends on the previous consonant, and it definitely serves absolutely the same semantic purpose. – noncom Sep 09 '21 at 09:06
  • I'm wondering how that "-er" rule would hold up against an EventListener, which can be designed/implemented in many ways (from an interface close to the data it manipulates, to a class enclosing the logic of all events from some endpoint). – Rogue Jun 21 '23 at 13:26
2

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.

BЈовић
  • 14,031
  • 8
  • 62
  • 82
  • 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
2

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.

mmdemirbas
  • 507
  • 1
  • 5
  • 10
anon
  • 1,474
2

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.

tp1
  • 1,902
  • 11
  • 10