-1

I currently have several "manager" classes in a project I am working on but have seen a lot of things that advise you to not use manager classes but don't seem to provide any alternatives in my situation. I have a ClickManager which contains a map of "clickable" objects and a ConfigManager which is responsible for loading and saving config files as the config class comes from an API I am using and is too stupid to load itself.

What are some alternatives to using "manager" in these cases?

user2248702
  • 2,741
  • 7
  • 41
  • 69
  • If by 'Manager', you mean a singleton object - there is nothing wrong with doing this. – Amir Afghani Jul 05 '14 at 02:57
  • If the only function of your click manager is to contain objects, a better name would be "ClickableContainer" because it describes its function better. If it performs a function with them, put that in the class name. For your config manager, perhaps looking at Spring or another IoC framework to configure your objects provides a better solution. Otherwise, something like "ConfigurationPersister" may describe its function better. – Erwin Bolwidt Jul 05 '14 at 03:27
  • Related: [How to avoid calling everything a “Manager”?](http://stackoverflow.com/questions/1866794/naming-classes-how-to-avoid-calling-everything-a-whatevermanager) – Frank Kusters Oct 06 '14 at 11:03

1 Answers1

7

Ward Cunningham once said (1) that every programmer should have a dictionary and a thesaurus on his or her desk. There's also a saying that there are only two hard problems in computer science: cache invalidation and naming things. (2)

The point is that naming things is important, and it's hard, and it's often neglected. This is why there are classes named Data and Manager littered around many code bases.

There are at least two potential things going on here. One is that the class is doing something reasonable, and it just needs to have a good, concise, descriptive name applied to it. For example, with ClickManager, does it dispatch events to the clickable objects? If so, maybe it's a Dispatcher. Does it lay out the clickable objects? Maybe it's a Positioner. Does it contain the clickable objects (as Erwin Bolwidt suggested)? Maybe it's a Container. Does it execute something in response to a click? Maybe it's an InteractiveCommand. It's sometimes helpful to think more specifically about what a class is doing in order to come up with a good name.

Another possibility is that the class has too many responsibilities, that is, it violates the Single Responsibility Principle. This is often the reason that something is hard to name, because it does a bunch of different stuff. Suppose the class simultaneously contains clickable objects, dispatches events to them, positions them, and executes commands. It's no wonder that it's hard to come up with a name other than Manager because it's doing all of these related, but independent functions. (Note that in many UI toolkits, these responsibilities have been separated into different classes.)

If this is the case it might be advisable to do some refactoring of a big Manager class into smaller classes, each of which has fewer (or one) responsibilities. It should be easier to come up with better names for those classes.

(1) I think it was at an OOPSLA about ten years ago.

(2) And off-by-one errors.

Stuart Marks
  • 127,867
  • 37
  • 205
  • 259