Thread: Help me name a class

This is just a hypothetical example - I'm just trying to learn how to name classes better.

Let's say you have a program that (amongst other things) will be required to start and stop other processes, and perhaps to communicate with them in some way to pass on some request (doesn't really matter what).

Now, you'll probably want to have a class called something like "Process", which will have an interface consisting of start(), stop(), and doSomething(). The Process class will communicate with the process (using CORBA or COM or whatever) to tell them to start, stop, or do something. Easy enough.

Okay, now say you have another class that maintains a list of these Process objects. It will receive requests for processes to start or stop or doSomething, and will find the required Process object and call the required method.

So, the question: What do you call this "manager" class? ProcessManager? I think naming classes with "Manager" in the name is a poor practice. But what? Something like ProcessList doesn't seem descriptive enough, as the class does more than that - it takes requests and passes them onto Processes, and might have some business logic of its own. So is there any decent name for this class?

I've heard it's a good idea to avoid naming classes so that they end in "er". So ProcessManager, ProcessController, etc are out. Anyone agree or disagree with this practice? Any suggestions for a good name?

The example is just a contrived one, but I often come across this problem, and found myself trying to think of something better than SomethingManager.

Thanks,
Just

Hmmm... I think ProcessManager sounds find to me. I've never heard you should "avoid naming classes so that they end in 'er'". I don't quite see why you would... consider what classes are... they're prototypes to objects that perform a task. Like for instance... managing or operating...

I'd say name a class that seems most comfortable to you. Don't conform to some ridiculous rule that really holds no logical grounds and can leave you searching through library files to find what you named a particular class because it something that isn't completely intuitive to you.

Thanks for that SlyMaelstrom. While googling on this topic, I came across this quote:

"Challenge any class name that ends in "-er" (e.g. Manager or Controller). If it has no parts, change the name of the class to what each object is managing. If it has parts, put as much work in the parts that the parts know enough to do themselves."
- Object-Oriented Programming by Peter Coad & Jill Nicola, Prentice Hall

This is, according to the book, known as the "er-er Principle", and although I've never heard anyone refer to it by that name, I have heard other developers question class names ending in "er". I'm not sure if I agree with this advice or not.

Any other opinions?

I think they just called it the "er-er rule" to help you remember "Manager" and "Controller". Nothing wrong with a Player class.

Daved, the example of mine was purely theoretical, made up to explain my question. But your point that avoiding classes that need to end in "Manager" does make sense.

So, in this theoretical example, how could this be avoided? What would be an improved design?

Depends on the type of Manager class you have developed. On the case you are developing a manager class just to act on data throughout your object instances, you are probably better off with static member functions. You really don't need a manager class for that. This is probably the most common of OO design mistakes; A completely irrelevant manager class.

For instance, imagine yourself wanting a function to activate all your CButton objects. Instead of making ActivateAllButtons() a member of a manager (or handler) class, you will be better off making it a static member function of CButton.

Of course, if you need to provide a function to act on all instances of the CButton class but you need that function to be polymorphic, then you probably just found a good candidate function for a manager class (although it could still be debated by some more strong defenders of the er-er principle that you still wouldn't need one).

The er-er principle basically tries to provide the idea that you don't need manager and handler classes in good OO design.

Originally Posted by Mario F.

Depends on the type of Manager class you have developed. On the case you are developing a manager class just to act on data throughout your object instances, you are probably better off with static member functions. You really don't need a manager class for that. This is probably the most common of OO design mistakes; A completely irrelevant manager class.

This is a good example unless (using the original example for discussion purposes) you want two groups of Processes that are (ahem) managed separately.

For example, let's say we're writing a simulator of a unix operating system. Processes can be grouped in various ways (eg by user-ID, by user-group, by priority, by parent process, etc). But each grouping is a collection of processes -- and some processes may be listed in more than one collection. Under unix, a process can actually be the parent of other processes. So, if a parent process wants to kill all its children, it would probably send a signal to each of its children, rather than sending a signal to all processes executing in the system.

In this case, I would probably name the basic "manager" class to something like ProcessCollection or ProcessList. Further details of the design would determine if a grouping by (say) user-ID is an instance of this class, or an instance of some derived class.

Originally Posted by Mario F.

For instance, imagine yourself wanting a function to activate all your CButton objects. Instead of making ActivateAllButtons() a member of a manager (or handler) class, you will be better off making it a static member function of CButton.

Same idea applies as above: all CButton objects would (presumably) be components on a Window object, but there might be multiple windows with their own CButtons. If you wish to activate all CButtons in a window the Window class would probably have the role of "ButtonManager".

And that is, I would suggest, the more important design principle. Management of a group of objects might be a role of some object. But managing those objects is not typically the end goal -- the end goal is something that is achieved by managing those objects plus a bit more. A Window object might manage a list of CButton (and other GUI elements), but that is not its sole purpose. The "bit more" will be a characteristic of the Window class -- and probably provide clues on how to name it "Window" rather than "CButtonManager".

Originally Posted by Mario F.

The er-er principle basically tries to provide the idea that you don't need manager and handler classes in good OO design.

Usually because such classes are doing more than being managers or handlers.

Absolutely grumpy.

Perhaps the whole idea is better explained considering that after all, objects are supposed to manage themselves, hence the argument against manager classes. However, collections are indeed a strong contender for managers. Maybe not explicitly under most situations (hence the need to drop the "Manager" or "Handler" monikers), but conceptually. And I'm sure someone can come up with other possible situations.

It is though a fact that we do make a lot of use of manager classes, when in fact we are just acting on object data. Well, at least I do despite all that is said about this issue. I find it hard to break off the habit.

And at the end of the day manager classes are not that evil. They surely don't hurt. That is why I have mixed feelings about this "rule".