有哪些类名表明需要重构？
我遇到了一些文章，例如 这篇文章，这些文章表明一些单词不应该用作类名的一部分。 当一个类的名称中包含这些单词之一时，就意味着应该重构或重新设计代码。
示例：
Manager
原因：由于几乎所有类都“管理”某些东西，并且“Manager”的含义非常广泛，因此人们可以将很多职责交给“Manager”类，同时仍然可以声明该类“只做一件事”。 因此，用“Manager”命名一个类并不能说明该类的实际用途。 前面提到的文章“在没有‘管理器’的情况下命名 Java 类”，表明了这一点：
例如，以一个名为“UrlManager”的类为例，您无法判断它是否池化 URL、操作 URL 或审核 URL 的使用。 从名称可以看出，这不是一个 URL，但它确实可以与它们一起使用。 另一方面，名称“UrlBuilder”可以更好地描述该类的功能。
另一个例子：
Helper
原因：像“ThreadHelper”这样的类名让人想知道为什么需要它以及为什么它不能只是“Thread”类的一部分。 它实际上是适配器还是装饰器？ 如果是这样，就这样命名。 “Thread”类是否已经承担了太多责任？ 如果是这样，请重构并为新类指定一个有意义的名称。 “帮助者”没有提及它在做什么或如何提供帮助。
类名中还有哪些其他单词表明需要重构或重新设计并且应该避免？ 为什么？
编辑：我认为这些词被大量使用，因为
- 它们通常具有广泛的含义
- ，可以适应几乎所有上下文，
- 它们阻止设计师思考更好的设计或名称，
- 人们认为可以使用它们
这本书干净代码列出了更多内容，但没有给出原因：
避免在类名称中使用 Manager、Processor、Data 或 Info 等词。
如果有人能为他们提供可能的原因，那就太好了。
相关问题：
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:
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
实用程序。 检查克里斯·米萨尔的博客条目了解原因。Utils. Check this Chris Missal's blog entry for why.包含非 7 位 ASCII 字符的任何名称。
我真的无法理解甚至无法编辑印地语字符。
Any name that contains characters that are not 7bit ascii.
I really cannot understand or even edit Hindi characters.
一般来说，我最不喜欢的标识符是：
My least favorite identifiers in general are:
冠词（
The、A、An）代词和名称（
我的、他们,John)数字，规范版本除外 (
2,3,5000)蓬松形容词 (
快速、智能、好、更好）大多数团队都不懂的外语 (Ελληνικά)
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 (Ελληνικά)
我认为这个问题应该从为任何媒体选择正确名称的大局来看待。 当我的妻子要求我从壁橱里拿一些东西时，我怎么知道她指的是哪个壁橱？
也许我的类的对象确实创建按钮，那么为什么不将其称为ButtonFactory呢？ 也许该对象确实管理临时文件的生命周期，所以我们将其称为 TemporaryFileManager。
当您没有足够的上下文信息时，问题就会出现。 在创建可重用组件时，这尤其困难：我的 TemporaryFileManager 可能是通用 Manager 类的子类，而我的 ButtonFactory 可能是 WidgetFactory 的特例。
只要名称描述了该事物在其上下文中的作用就可以了。 这就是上面提到的文章的内容。
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.
1）任何少于 3 个字符的内容都会让我感到不安。 这确实会损害可读性，因为至少 3 个字符通常会给出至少一个元音。 就我个人而言，我尝试使用至少 5 个字符。
2）我最讨厌的一个问题是以class结尾的类名（例如：personClass或buttonClass），因为它有点脱离了你正在创建一个对象而不是一个类的事实。 类似地创建一个类的实例我觉得还可以（例如：blueButton，redLabel），因为它更容易阅读，但是类的事情可能会变得非常烦人。
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.
列出不好的想法可能需要一段时间才能放弃，就在我的脑海中，我可以想到很多不好的名字：读者、作家、工厂、项目、定时器、接收者、发送者等等。
基本上，避免使用那些不给你任何好处的名字 。类是什么或其在更大范围内的作用的上下文。 有时它不一定像
IHelpToSendXMLDataToTheServer那样夸张，但XMLBroadcastUtil可能不会太糟糕。 有些人甚至在类名中添加特定的前缀、后缀来指定它与哪个模块一起使用。 然而，我认为这是命名空间/包的作用的一部分。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 possiblyXMLBroadcastUtilwouldnt 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.如何编写不可维护的代码上建议的所有内容。
Everything suggested on How To Write Unmaintainable Code.
这
总是一个糟糕的决定。
This
that's always a bad call.
抽象的
模板
模型
工厂
对象
这些都是非常通用的，其中一些可以从类定义中显而易见。 其他的显然在一小段文档中得到了更好的说明（易于参考是喜欢 resharper 的原因之一）
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)
任何可能覆盖标准类的东西（例如：Java 中的
Comparator、Iterable和 c.），除非您理解并明确打算导致这种行为。Anything that may override standard classes (ex:
Comparator,Iterable&c. in Java), unless you understand and specifically intend to cause this kind of behaviour.