In general it’s good to avoid words like “handle” or “process” as part of routine names and class names, unless you are dealing with (e.g.) file handles or (e.g.) unix processes. However abstract classes often don’t really know what they’re going to do with something besides, say, process it. In my current situation I have an “EmailProcessor” that logs into a user’s inbox and processes messages from it. It’s not really clear to me how to give this a more precise name, although I’ve noticed the following style matter arises:
- better to treat derived classes as clients and named the base class by the part of the functionality it implements? Gives it more meaning but will violate is-a. E.g. EmailAcquirer would be a reasonable name since it’s acquiring for the derived class, but the derived class won’t be acquiring for anyone.
- Or just really vague name since who knows what the derived classes will do. However “Processor” is still too general since it’s doing many relevant operations, like logging in and using IMAP.
Any way out of this dilemma?
Problem is more evident for abstract methods, in which you can’t really answer the question “what does this do?” because the answer is simply “whatever the client wants.”
6
The problem is not the name, but that you are putting too much in one class.
In your example class, some parts are very concrete (how the mails will be obtained). Other parts are very abstract (what you will do with the mails).
Better to do this with seperate classes, than with inheritance.
I suggest:
-
an abstract MessageIterator, subclassed by a POPMailBoxDownloader
-
another class that OWNS a POPMailBoxDownloader and does something with the messages.
1
If I cannot find a good name for a class I write an inline code documentation for the class. It describes the purpose of the class in one scentence. Usually I can derive a good name for the class from this description. This is also helpful for abstract classes.
If the description of class is “Logs into a user’s inbox and processes messages from it”, I would suggest “InboxProcessor” as a class name. If a derivative class has “Logs into a user’s inbox and moves spam email to a spam folder” as description, I would choose “InboxSpamMover” as a name.
I do not see a problem when using generic names like “processor” if it reflects the generic purpose of an abstract class.
If you have problems with describing the purpose of a class in one or two scentences, then you might have a design problem. Maybe the class is doing too much and violates the Single Responsibility Principle. This also applies to abstract classes.
0
To paraphrase Frank Zappa, it are what it is and should be named that way. Your example just doesn’t dig deep enough into what kind of processing is going on. Is it an EmailToTroubleTicketProcessor, an EmailGrammarCorrector or an EmailSpamDetector?
Problem is more evident for abstract methods, in which you can’t
really answer the question “what does this do?” because the answer is
simply “whatever the client wants.”
That’s not exactly true; the question you can’t answer for something abstract is “how does it do what it does?” because that’s implementation-specific. If an EmailSender class has a DeliveryStatus deliver(Email e) method, there’s an implied contract that an implementation will take an email, try to deliver it and return some status about how it went. You don’t care whether it connects to a SMTP server or prints it out to be strapped to a homing pigeon as long as the implementation does what was promised. Abstracts just quantify that promise so an implementation can say, “yeah, I do that.”
2
Think about why it’s bad to use such words. Are they descriptive? What words are there to describe the classes? EmailBaseClass? Could that be more descriptive than say EmailManager or something similar? The key is to have an insight about the class in question, so find proper verbs or nouns. Treat your code like it was poetry.
3