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.