March 29, 2006
Alan Green rails against the meaninglessness of
How many classes do you come across named
SomethingManager? Any decent sized commercial system seems to have plenty –
ConfigurationManager, or even, sadly,
A quick look at the dictionary entry for "manager" and "manage" gives at least ten different meanings - from "to make and keep compliant" through to "to achieve one's purpose". I remember one day when the receptionist briefly retitled herself as Switchboard Manager. The common semantic to all these definitions seem to be a vague "looks after stuff".
This imprecision makes Manager a bad word to use in naming classes. For instance, take a class named
UrlManager – you cannot tell whether it pool URLs, manipulates URLs or audits the use of them. All the name tells you is that this class does something with URLs. On the other hand, the name
UrlBuilder provides a much clearer picture of what the class does.
In the Java world, the Manager suffix is thrown around a lot. Almost anywhere you have a class that is responsible in any way for other objects, it automatically earns the Manager label.
There's nothing more ambiguous than a
SomethingManager. Avoid this word. Alan proposes a few alternatives in his blog post that might be helpful in narrowing down what your class actually does.
Giving your classes and objects good, descriptive names isn't easy. Steve McConnell provides a few helpful guidelines for routine naming in Code Complete:
- Describe everything the routine does
And we mean literally everything. If that makes the name ridiculously long, the name isn't the problem. Your routine is.
- Avoid meaningless, vague, or wishy-washy verbs
PerformServices(). Be specific. What does it do? If you can't answer that question succinctly, it may be time to refactor the code until you can.
- Don't differentiate routine names solely by number
I include this only for completeness. If you ever find yourself writing
OutputUser2(), God help you. And God help the team you work with.
- Make names as long as necessary
According to McConnell, the optimum name length for a variable is 9 to 15 characters; routines tend to be more complex and therefore deserve longer names. Make your names as long as they need to be in order to make them understandable.
- For functions, try using a description of the return value
An easy, straightforward rule. Some examples are
- Use opposites precisely
Open(), there should be a
Close(); for every
Delete(); for every
- Establish conventions for common operations
This is best illustrated with an example, and McConnell provides an excellent one:
Now how do I get an Id again?
I'd say renaming classes and variables is one of my most frequent refactoring activities. Creating good names is hard, but it should be hard, because a great name captures essential meaning in just one or two words
It's difficult to tell what something should be named until you're completely finished writing it. And like most code, it's never quite done, so the name may change over time. Succinct, descriptive variable, object, and function names can make the difference between Daily WTF code and… well, code you'd actually want to work on.
Posted by Jeff Atwood
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:
"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"
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.
I think that there are many cases where manager should not be used, but there are many, many more cases where it fits right. For example, think of plug-ins.
What should happen with plug-ins? They should be loaded, executed, queried, and unloaded. So for the definition of manage (one to handle, direct, govern, or control in action or use), the word manager fits perfectly; the class would control the plug-ins.
CPluginManager is a nicer looking name than CPluginController, and they both imply the same meaning. Also, the querying part adds more than just controlling, so CPluginController is misleading.
That's because controller is even more ambiguous than manager. How about cPluginLoader?
Ah, the good old posts where there were fewer comments.
If you ever find yourself writing OutputUser1() and OutputUser2(), God help you. And God help the team you work with.
Yes, I agree with some exclusions. Cocoa has assertions named like that NSAssert1, NSAssert2.. NSAssert5 (#defined for programmers convenience), each suffix indicating the variable number of arguments it takes. :)