Alan Green rails against the meaninglessness of SomethingManager:
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2006/03/i-shall-call-it-somethingmanager.html
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2006/03/i-shall-call-it-somethingmanager.html
Well I feel smart. I just renamed every *Manager class to *Helper. 
I’m not so sure on this one. In my UI layer I have IconManager, FontManager, and SoundManager classes. These obviously are made to “manage” common resources. I “get” the resource from the manager (most are singletons) and then show/play it using methods on the resource. I also have UIController and StateController classes. These don’t have the Manager postfix because they actually “control” something (think MVC here). I could have called these the UIManager and StateManager classes but that just doesn’t seem right.
Maybe the Java world throws the word manager on the end of everything even though it isn’t warranted. But that doesn’t mean that the word should be tossed out. It just means that people need to be careful about its use. And the alternatives aren’t really any better…
If you don’t know what to name it call it Monkey:) It is doubtfull that anyone would ship something named Monkey.
Amen! In response to a post of mine on this topic, Pete went through a thesaurus and found a list of useful alternatives to Manager: http://www.developingstorm.com/2005/09/managermanager.php
Some are clearly whimsical (Juggler?) but can be useful for at least shaking things up instead of yet another Manager.
That’s a nice collection of naming rules, I really should dust off my copy of Code Complete and revisit it.
I commented on Alan’s post back in November, here: a href="http://www.lenholgate.com/archives/000574.html"http://www.lenholgate.com/archives/000574.html/a.
Agree 100% that good names are well worth all the effort required.
Agreed giving something a good name makes it so much easier for people maintaining the code ( even if its same person as the author ). No excuse for not doing this no auto refactoring support is so prevelant.
I think that the problem isn’t so much the word manager as the fact that the class has a verb in it’s name. This is a sign of procedurally written code. Separation of code and data.
In an object oriented world the class name is a noun… it has instance members. And the methods are in the same class, not in a separate Manager/Controller/Handler/Accessor class taking the noun class as a parameter.
“Don’t differentiate routine names solely by number I include this only for completeness. If you ever find yourself writing OutputUser1() and OutputUser2(), God help you. And God help the team you work with.”
I’m lookin at code that does this right now…lucky i believe in god eh
It’s funny how we programmers need to re-learn these same lessons every few years. I first read about this “code smell” in the Taligent programming guide:
“The presence of a manager object typically signifies a problem with your design, the result of which is a client interface expressed as objects outside the client’s problem domain. The word manager in a class name often indicates this problem.”
This is Taligent’s solution to the problem:
“For example, suppose you want a function to apply to multiple windows, such as CloseAllOpenWindows. The wrong way to do this is to have clients call a TWindowManager class. The correct way is to make CloseAllOpenWindows a static member of TWindow. It is associated with the class it applies to, and its multiobject function is reflected by its being static.”
Of course, this solution requires that classes track their instances.
common sense… (you would think)…
and I was just reading this:
http://blogs.teamb.com/CraigStuntz/archive/2006/03/30/IBXSchemaCache.aspx
“I needed to know the primary key of a table for some code I was writing. Simple enough to get the information from the system tables, but this code would be called quite frequently, so I thought I would need to cache the information. Then I realized that IBX already does this. Look at TIBDatabase.In_Key”
simple enough?
In_Key?
WTF!
Avoiding the term “Manager” is the most idiotic coding advice I’ve heard in a long time. The FooManager is the central class that combines (usually application-wide) resources and functionality for Foo, what’s unclear about that? And if you don’t make such a central class the functionality will be spread across unrelated classes which is worse, not better. I guess Alan Green just ran out of things to rant about. Maybe he should go back to hating Goto.
Because simply calling it Foo would force me to call what is now the Foo class something else. The FooManager class “manages” Foo’s. It is not a Foo itself. In many cases Foo’s can’t manage themselves or probably shouldn’t. Some would say that Foo’s should be self managing but that only works if I have complete control over the Foo class and there are no interdependecies. For example, a ResourceManager might manage a lot of different types of resources. It might also need information about the current context to know how to return or manage specific instances of resources. Having this logic centralized into a single manager class is more desirable than spreading this same knowledge across multiple classes. Especially when it is solely for the purpose of removing the name “manager” from a class name.
There are times when it is resonable to have a class whose purpose/name involves “managing”. It is the “overuse” of this name that needs correcting. Not the specific use of the name itself.
When I come across one of these vaguely-named routines it’s my custom to ask for a more detailed description. There’s almost always an “and” in there somewhere. That’s when I pounce.
The FooManager is the central class that combines (usually application-wide) resources and functionality for Foo, what’s unclear about that?
Why not call it “Foo” then? What does “Manager” add?
I say it adds a whole lot of… nothing.
Oh man. I actually had a huge laugh over someone dispensing this exact technique like it was gospel. He’d make business objects, and then he’d write “manager” objects to “manage” them… whtever the hell that meant. His “managers” would contain all the code to persist and retrieve the “managed” object from a DB, except when he got more than one (an array of objects, for instance), where he’d then have a “gateway” object (if that ain’t an arbitrary thing to do, I don’t know what is).
His “user manager” object would thusly persist the object and also login/logout the user, and a host of other things. Argg…
He’d make business objects, and then he’d write “manager” objects to “manage” them… whtever the hell that meant.
It’s a perfect model of corporate america-- one class working, and a ten layer deep hierarchy of classes “managing” that class! Pure efficiency!
While I agree (and I do agree, how could I possibly _dis_agree?), sometimes I find pretty hard, dammit, to find good names. This is particularly the case when moving from a concrete-but-rigid architecture to a more abstract-data-driven-and-thus-flexible one. To make things (i.e. naming) even worse, sometimes you have to wrap and adapt your way around existing classes and their idiosyncrasies. So then you (or rather, I) get a lot of FooWrappers and BarAdapters in addition to those BooManagers and FarHandlers…
The Manager idea is found in Object Oriented design textbooks. The Manager class manages (or controls, or coordinates) the Use Case.
Although, from the examples given above, it doesn’t seem like people use it that way; most people probably don’t even realize this is how it’s “supposed” to be done.
It requires you to have a clear idea of your Use Case, in which case you could probably name it better, I suppose.
Ok, I know this is old, but this needs to be added.
On a project I have worked on had the priceless classes CThing, CThingy and CThingOwner - the last class really should have been CThingyOwner but whether that came later or not I can’t really say the “modification” history is some what clouded.