Help me name a class

This is a discussion on Help me name a class within the C++ Programming forums, part of the General Programming Boards category; This is just a hypothetical example - I'm just trying to learn how to name classes better. Let's say you ...

  1. #1
    Registered User
    Join Date
    Mar 2003
    Posts
    28

    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
    "C++ is like jamming a helicopter inside a Miata and expecting some sort of improvement."
    - Drew Olbrich

  2. #2
    Devil's Advocate SlyMaelstrom's Avatar
    Join Date
    May 2004
    Location
    Out of scope
    Posts
    4,066
    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.
    Sent from my iPad®

  3. #3
    Registered User
    Join Date
    Mar 2003
    Posts
    28
    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?
    "C++ is like jamming a helicopter inside a Miata and expecting some sort of improvement."
    - Drew Olbrich

  4. #4
    The larch
    Join Date
    May 2006
    Posts
    3,573
    Just follow your common sense. It would be good if the class name gave you an idea what it is for, but AClassThatFirstOpensAFileThenProcessesTheDataAndFi nallyCleansUp doesn't seem very good.

    What's the problem with -er? Wouldn't Player be a good class name in a game?

  5. #5
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,046
    I think they just called it the "er-er rule" to help you remember "Manager" and "Controller". Nothing wrong with a Player class.
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  6. #6
    Registered User
    Join Date
    Jan 2005
    Posts
    7,317
    I had not heard of this principle before (or had forgotten it), but after a little research I can't say that it is wrong. I also don't know whether I agree with it either. Regardless, with a rule like this you should strive to understand what it is saying and why. Following the rule blindly won't necessarily make your code better, as you won't necessarily know how to fix it. If you create this manager class despite the rule, then your code will still be fine, so don't worry too much about it. Just take some time to try to understand what is going on.

    The first step would be to understand that it is not a naming rule. Naming your class something other than ProcessManager or ProcessController will not solve the problem. The point of the rule is to avoid these types of classes in the first place.

    So go ahead and name your class ProcessManager, then do some studying on the er-er principle if and when you have time to figure out if there is a better design for your program.

  7. #7
    Registered User
    Join Date
    Mar 2003
    Posts
    28
    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?
    "C++ is like jamming a helicopter inside a Miata and expecting some sort of improvement."
    - Drew Olbrich

  8. #8
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,412
    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.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  9. #9
    Registered User
    Join Date
    Jun 2005
    Posts
    6,208
    Quote 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.
    Quote 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".
    Quote 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.
    Last edited by grumpy; 09-09-2006 at 06:44 AM.

  10. #10
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,412
    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".
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Class design problem
    By h3ro in forum C++ Programming
    Replies: 10
    Last Post: 12-19-2008, 08:10 AM
  2. Two conceptual questions
    By AntiScience in forum C++ Programming
    Replies: 3
    Last Post: 11-01-2007, 11:36 AM
  3. Defining derivated class problem
    By mikahell in forum C++ Programming
    Replies: 9
    Last Post: 08-22-2007, 02:46 PM
  4. matrix class
    By shuo in forum C++ Programming
    Replies: 2
    Last Post: 07-13-2007, 01:03 AM
  5. Abstract class problem
    By VanJay011379 in forum C++ Programming
    Replies: 9
    Last Post: 07-31-2002, 01:30 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21