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.
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.
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”. […]
This imprecision makes Manager a bad word to use in naming classes.
I know this is a pretty old thread but the concept of ‘SomethingManager’ has gripped me for years since I first encountered the concept and I’ve been mulling it over ever since. To me it seems that the business of software is a multi-level occupation that involves essentially three layers.
We’re not only in the business of creating software, we’re in the business of creating processes to create software and to that end we’re in the business of creating organizations which create processes to create software.
It’s pretty well known according to Conway’s Principle that organizations that design systems (i.e. processes or software) will essentially design systems that mirror the communication patterns within the organization and which reflect the quality of communications within the system. This type of self-similarity cannot be avoided, especially long-term and at scale.
If the *Manager pattern is an anti-pattern at the software level, my instinct tells me it’s also an anti-pattern at the org level and these people who are going around managing the rest of us are pretty much designed to enforce compliance and whatever vacuous purpose the manager class serves.
I feel we ought to extrapolate from the code that if the SomethingManager doesn’t serve in the code it also doesn’t serve in the culture.
