What are some class names that would signal a need for refactoring? [closed]

问题

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 6 years ago.

I came across a few articles like this one, which suggest that some words should never be used as part of a class name. When a class has one of those words in the name, it means the code should be refactored or redesigned.

Example:

Manager

Reason: Since almost all classes "manage" something and the meaning of "Manager" is very broad, people can put a lot of responsibilities to a "Manager" class while still being able to claim the class does "only one thing". As a result, naming a class with "Manager" does not say much about what the class actually does. The article mentioned earlier, "Naming Java Classes Without a 'Manager' ", showed this point:

For instance, take a class named "UrlManager" - you cannot tell whether it pool URLs, manipulates URLs or audits the use of them. All the name tells you is that this is not a URL, but it does somehow work with them. On the other hand, the name "UrlBuilder" gives a much better picture of what the class does.

Another example:

Helper

Reason: A class name like "ThreadHelper" makes people wonder why it's needed and why it cannot just be part of the "Thread" class. Is it actually an adapter or a decorator? If so, name it that way. Is class "Thread" taking too much responsibility already? If so, refactor and give the new class a meaningful name. "Helper" says nothing about what it's doing or how it's helping.

What are other words in a class name that would signal a need for refactoring or redesign and should be avoided? Why?

Edit: I would think those words are used a lot since

• they generally have broad meanings
• they can fit in almost all contexts
• they stop designers thinking about better designs or names
• people believe it's OK to use them

The book Clean Code listed more but no reasons were given:

Avoid words like Manager, Processor, Data, or Info in the name of a class.

It would be great if someone could provide possible reasons for them.

Related questions:

What’s the best approach to naming classes?

回答1:

Utils. Check this Chris Missal's blog entry for why.

回答2:

Any name that contains characters that are not 7bit ascii.

I really cannot understand or even edit Hindi characters.

class हिन्दी:হিন্দী ঠার
{
  // argh.. 
}

回答3:

My least favorite identifiers in general are:

1. Misspelled words. GEM had palette spelled as "pallete" in all its API calls. Maddening.
2. Identifiers where I can't tell if a character is a 1 or an l, or a 0 or an O.
3. George Carlin's seven dirty words.

回答4:

Articles (The, A, An)

Pronouns and names (My, Their, John)

Numbers, except for spec versions (2, 3, 5000)

Fluffy adjectives (Fast, Smart, Good, Better)

Foreign language that the majority of the team doesn't understand (Ελληνικά)

回答5:

I think this question is to be seen in the bigger picture of picking the right name for any medium. When my wife asks me to get that something from the closet, how am I supposed to know what closet she means?

Maybe objects of my class do create buttons, so why not call it a ButtonFactory? Maybe that object does manage the lifetime of temporary files, so let's call it TemporaryFileManager.

The problem arises when you don't have enough contextual information. This especially hard when creating reusable components: my TemporaryFileManager may be a subclass of a generic Manager class, and my ButtonFactory may be a special case of WidgetFactory.

As long as the name describes what the thing does in its context I'm alright. And that's what the mentioned article is about.

回答6:

1) Anything less than 3 chars really gets on my nerves. It really hurts readability, since 3 chars at least usually gives you at least one vowel. Personally, I try to use at least 5 chars.

2) One pet peeve I have is class names ending in class (ex: personClass or buttonClass) since it kind of takes away from the fact that you're making an object, not a class. Making instances of a class similarly I find ok (ex: blueButton, redLabel), since it's easier to read, but the class thing can get really annoying.

回答7:

Listing bad ideas could take quit awhile, just off the top of my head I could think of a lot of bad names: Reader, Writer, Factory, Item, Timer, Reciever, Sender, etc etc.

Basically, avoid names that give you no context for what the class is or its role in the bigger picture. It doesn't have to be sometime as over the top as IHelpToSendXMLDataToTheServer, but possibly XMLBroadcastUtil wouldnt be terrible. Some people even go as far as adding particular prefex, suffix to class names to designate which module it works with. However, I would argue this is part of the role of the namespace/package.

回答8:

Everything suggested on How To Write Unmaintainable Code.

回答9:

This

that's always a bad call.

回答10:

Abstract Template Model Factory Object

These are all really generic, and some of them could be obvious from the class definition. Others are obviously better noted in a short bit of documentation (easy reference of which is one reason to like resharper)

回答11:

Anything that may override standard classes (ex: Comparator, Iterable &c. in Java), unless you understand and specifically intend to cause this kind of behaviour.

来源：https://stackoverflow.com/questions/1175481/what-are-some-class-names-that-would-signal-a-need-for-refactoring