命名类-如何避免把所有的东西都称为"<WhatEver>Manager"？[英] Naming Classes - How to avoid calling everything a "＜WhatEver＞Manager"?

问题描述

A long time ago I have read an article (I believe a blog entry) which put me on the "right" track on naming objects: Be very very scrupulous about naming things in your program.

For example if my application was (as a typical business app) handling users, companies and addresses I'd have a User, a Company and an Address domain class - and probably somewhere a UserManager, a CompanyManager and an AddressManager would pop up that handles those things.

So can you tell what those UserManager, CompanyManager and AddressManager do? No, because Manager is a very very generic term that fits to anything you can do with your domain objects.

The article I read recommended using very specific names. If it was a C++ application and the UserManager's job was allocating and freeing users from the heap it would not manage the users but guard their birth and death. Hmm, maybe we could call this a UserShepherd.

Or maybe the UserManager's job is to examine each User object's data and sign the data cryptographically. Then we'd have a UserRecordsClerk.

Now that this idea stuck with me I try to apply it. And find this simple idea amazingly hard.

I can describe what the classes do and (as long as I don't slip into quick & dirty coding) the classes I write do exactly one thing. What I miss to go from that description to the names is a kind of catalogue of names, a vocabulary that maps the concepts to names.

Ultimately I'd like to have something like a pattern catalogue in my mind (frequently design patterns easily provide the object names, e.g. a factory)

• Factory - Creates other objects (naming taken from the design pattern)
• Shepherd - A shepherd handles the lifetime of objects, their creation and shutdown
• Synchronizer - Copies data between two or more objects (or object hierarchies)

• Nanny - Helps objects reach "usable" state after creation - for example by wiring to other objects

• etc etc.

So, how do you handle that issue? Do you have a fixed vocabulary, do you invent new names on the fly or do you consider naming things not-so-important or wrong?

P.S.: I'm also interested in links to articles and blogs discussing the issue. As a start, here is the original article that got me thinking about it: Naming Java Classes without a 'Manager'

Update: Summary of answers

Here's a little summary of what I learned from this question in the meantime.

• Try not to create new metaphors (Nanny)
• Have a look at what other frameworks do

Further articles/books on this topic:

• What names do you find yourself prepending/appending to classes regularly?
• What’s the best approach to naming classes?
• Book: Design Patterns: Elements of Reusable Object-Oriented Software (Hardcover)
• Book: Patterns of Enterprise Application Architecture (Hardcover)
• Book: Implementation Patterns (Paperback)

And a current list of name prefixes/suffixes I collected (subjectively!) from the answers:

• Coordinator
• Builder
• Writer
• Reader
• Handler
• Container
• Protocol
• Target
• Converter
• Controller
• View
• Factory
• Entity
• Bucket

And a good tip for the road:

Don't get naming paralysis. Yes, names are very important but they're not important enough to waste huge amounts of time on. If you can't think up a good name in 10 minutes, move on.

推荐答案

I asked a similar question, but where possible I try to copy the names already in the .NET framework, and I look for ideas in the Java and Android frameworks.

It seems Helper, Manager, and Util are the unavoidable nouns you attach for coordinating classes that contain no state and are generally procedural and static. An alternative is Coordinator.

You could get particularly purple prosey with the names and go for things like Minder, Overseer, Supervisor, Administrator, and Master, but as I said I prefer keeping it like the framework names you're used to.

Some other common suffixes (if that is the correct term) you also find in the .NET framework are:

• Builder
  A type that use some parameters to construct an instance of a special type. Builder is usually a throwaway. It may not even need to allocate a variable.
  If the type needs to repeatedly create objects, please use Factory.
  if the type responsible for create multiple different type objects, please use Factories.
• Writer
  Write some variable into something.
• Reader
  Read something as variable.
• Handler
  Designed to deal with a situation or something.
• Container
  Can put something into it.

其他推荐答案

You can take a look at source-code-wordle.de, I have analyzed there the most frequently used suffixes of class names of the .NET framework and some other libraries.

The top 20 are:

• attribute
• type
• helper
• collection
• converter
• handler
• info
• provider
• exception
• service
• element
• manager
• node
• option
• factory
• context
• item
• designer
• base
• editor

其他推荐答案

I'm all for good names, and I often write about the importance of taking great care when choosing names for things. For this very same reason, I am wary of metaphors when naming things. In the original question, "factory" and "synchronizer" look like good names for what they seem to mean. However, "shepherd" and "nanny" are not, because they are based on metaphors. A class in your code can't be literally a nanny; you call it a nanny because it looks after some other things very much like a real-life nanny looks after babies or kids. That's OK in informal speech, but not OK (in my opinion) for naming classes in code that will have to be maintained by who knows whom who knows when.

Why? Because metaphors are culture dependent and often individual dependent as well. To you, naming a class "nanny" can be very clear, but maybe it's not that clear to somebody else. We shouldn't rely on that, unless you're writing code that is only for personal use.

In any case, convention can make or break a metaphor. The use of "factory" itself is based on a metaphor, but one that has been around for quite a while and is currently fairly well known in the programming world, so I would say it's safe to use. However, "nanny" and "shepherd" are unacceptable.