10

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
  • Do you have a source (and some context) for that "in general" claim? Also, an additional naming rule for the list - don't waste time looking for a perfect name that probably doesn't exist. If in doubt, give it the best name you can, add a longer description as a comment where it's defined if necessary, but you can always refactor later if someone doesn't like your choice or the perfect name suddenly occurs to you when you're doing something else.
    – user8709
    Commented Sep 5, 2012 at 22:23
  • 3
    @Steve314 - yes, Steve McConnell, Code Complete, 1st ed., Chapter 4 or 5 on routines. Extensive discussion on naming in these chapters, essentially concluding if you don't have a good name you probably don't have a good function.
    – djechlin
    Commented Sep 5, 2012 at 22:25
  • failing to find a good name may seem like a bad sign, but IMO you should know if the function is bad based on the function itself. Refactoring just because the English language wasn't custom-designed for your project is a bit daft. No, it's not an everyday issue, but you already decided you had an issue.
    – user8709
    Commented Sep 5, 2012 at 22:49
  • 1
    @Steve314 Programming is entirely about managing complexity, and if your brain can't come up with a word for something there's a pretty good chance it won't be able to manage the complexity of it when it has to do things like use it in bigger sentences or as part of bigger systems. It's actually not a bold claim to say inability to find a good name is a big cause to pause for concern. But this is discussed extensively in McConnell, I would recommend reading those two chapters at least although the entire book is worth reading cover-to-cover.
    – djechlin
    Commented Sep 5, 2012 at 22:54
  • the claims in Code Complete shouldn't necessarily be trusted. I'm aware of the books reputation, but I'm also aware of this. Besides, I've been managing complexity perfectly well for ages - mistakes happen, of couse, but when things go wrong, sometimes the problem is a function that's so simple it obviously can't be wrong, but is anyway.
    – user8709
    Commented Sep 5, 2012 at 23:17

4 Answers 4

Reset to default
10

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
  • This sounds exactly right. It sounds like if you find yourself naming something "processEvent" or a class "MessageProcessor," there's a good chance you could have designed over composition instead of derivation. In this case it's a tradeoff, as maintainers the flexibility can be useful but a client would be annoyed by wondering exactly what each function does (moreso than the maintainer).
    – djechlin
    Commented Sep 5, 2012 at 22:04
6

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
2

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
  • What about when the end function is in some sense terminal, so the abstract class is saying "and this here, do whatever you want with it?" e.g., the method has no access to state, void return type, no-throw.
    – djechlin
    Commented Sep 5, 2012 at 22:48
  • It's still the same thing. Even if your method is void doWhatYouDoWith(Email e), you could still call the class an EmailDisposer, which is specific enough to say what it does but general enough that how is up to the implementation. Although I think @KrisVanBael nailed it: if you've resorted to something that ambiguous, there may be too much under one roof.
    – Blrfl
    Commented Sep 6, 2012 at 0:38
0

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
  • "EmailBaseClass" would be like naming int age "ageInteger," only even worse since I would expect to derive plain text emails, MIME emails etc. from it. No need to describe what is preceded by the word abstract in the first place (this is Java). Do you have any particular insight for the base part of this class? And more insight still doesn't solve the problem of naming something that is going to be crossing an is-a relationship, I can either have something too vague or too general, I don't see a way out of this unless if I had more insight into having more insight.
    – djechlin
    Commented Sep 5, 2012 at 21:36
  • @djechlin - there's rare cases where ageInteger or something like it is actually appropriate. Hungarian notation is an abbreviated version from a context where it happened a lot. Certainly, there are times when you may need something along the lines of ageNumeric and ageString in the same scope, with an indication of the type in the name being the easiest and clearest way to disambiguate.
    – user8709
    Commented Sep 5, 2012 at 22:27
  • @djechlin I personally find it easiest to work with code which I can just peek at to gain an understanding. That is, names tell me what I'm working with. No need to know if systemController is an abstract base class or a leaf in a huge hierarchy. Of course this may be remedied with IDE(as I guess is the case with most Java development?) which can immediately inform the user about the contents and structure of the class so actually insightful names can't be justified in similar vein.
    – zxcdw
    Commented Sep 6, 2012 at 8:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.