More Manager thoughts
Bah, if it's a manager, call it a manager. If it were something else, you'd call it something else. There are a lot of things to manage in a software product, so you're likely to have a lot of managers.
I think I know what Nate meant, but let me poke some fun at this first because it struck me funny. I could pick half the words from the list of alternative for Manager I created and plug them into this sentence and they would be just as accurate.
Bah, if it's a coordinator, call it a coordinator. If it were something else, you'd call it something else. There are a lot of things to coordinate in a software product, so you're likely to have a lot of coordinators.
or
Bah, if it's a jockey, call it a jockey. If it were something else, you'd call it something else. There are a lot of things to jockey in a software product, so you're likely to have a lot of jockeys.
or
Bah, if it's a wrangler call it a wrangler. If it were something else, you'd call it something else. There are a lot of things to wrangle in a software product, so you're likely to have a lot of wranglers.
I think Nate was actually saying that Manager is common generic name for objects that work on other objects, so why not stick with it. I don't disagree with that notion of conforming to a standard, but in the case of using Manager to the exclusion of other names, I think that's a slippery slope. Often another words could be used to describe what sort of management was being performed that are more accurate or descriptive or would better differentiate the classes position in the object model.
This leads me to the second comment by my old buddy and star developer Bob. Bob points to an old Taligent C++ guide that says:
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. A centralized implementation, either within an address space or between address spaces, is just an implementation detail. 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.
In defense of Bob, he indicated he didn't agree in totality with the statement, he was pointing it out more as an anecdote. I've been pondering this advice a lot since then and I've reached the conclusion that it's just plain bad. Consider the example they give about TWindowManager and the call to CloseAllOpenWindows. They recommended making the call CloseAllOpenWindows a static on TWindow. How convenient that the example call was to close ALL open windows. It's an edge case where this design would work but what if you wanted to operate on a subset of windows. The reason you would use a manager type class is for exactly this reason. Perhaps calling the class TWindowSet would have been better than TWindowManager, but that's besides the point. I agree with the idea of asking objects to operate on themselves, but a classes static interface is not an object. It's just a namespace of functions related to a class of objects. An instance of class that manages, jockeys or wrangles a bunch of other object is an object and a better design.
Comments