What are some class names that would signal a need for refactoring?
我看到了一些像这篇文章这样的文章，它们建议不要将某些单词用作类名的一部分。当一个类的名称中有一个单词时，这意味着代码应该被重构或重新设计。
例子：
经理
原因：由于几乎所有的班级都在"管理"一些东西，"经理"的含义非常广泛，人们可以把很多责任放在"经理"班上，同时仍然能够声称班级只做了"一件事"。因此，用"manager"命名一个类并不能说明该类实际上做了什么。前面提到的文章"命名Java类没有"管理器""，说明了这一点：
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.
另一个例子：
帮手
原因：像"threadhelper"这样的类名让人们想知道为什么需要它，为什么它不能只是"thread"类的一部分。它实际上是适配器还是装饰器？如果是这样的话，就这样命名。"线程"类已经承担了太多的责任了吗？如果是这样，请重构并为新类提供一个有意义的名称。""帮助者"对它在做什么或它如何帮助什么都不说。
类名中还有什么其他的词可以表示需要重构或重新设计，应该避免使用这些词？为什么？
编辑：我想这些词从那以后就被大量使用了。
- 它们通常具有广泛的含义。
- 它们几乎适用于所有环境
- 他们阻止设计师思考更好的设计或名称
- 人们认为使用它们是可以的
书的清洁代码列出了更多，但没有给出原因：
Avoid words like Manager, Processor, Data, or Info in the name of a class.
如果有人能为他们提供可能的理由，那就太好了。
Related questions:
What’s the best approach to naming classes?
包含非7bit ASCII字符的任何名称。
我真的不能理解甚至编辑印地语字符。
1 2 3 4 | class ??????:?????? ??? { // argh.. } |
一般来说，我最不喜欢的标识符是：
条款(
代词和名称(
数字，规范版本除外(
蓬松的形容词(
大多数团队不懂的外语(_λλη_κ？)
我认为这个问题可以从为任何媒介选择正确名称的大局中看到。当我妻子要我从衣橱里拿东西的时候，我怎么知道她是什么意思？
也许我类的对象会创建按钮，那么为什么不称它为ButtonFactory呢？也许那个对象确实管理了临时文件的生存期，所以我们称它为临时文件管理器。
当你没有足够的上下文信息时，问题就出现了。这在创建可重用组件时尤其困难：我的TemporaryFileManager可能是通用管理器类的子类，而我的ButtonFactory可能是WidgetFactory的特殊情况。
只要这个名字描述了它在上下文中的作用，我就没事了。这就是上面提到的文章的内容。
1)如果少于3个字符，我真的很紧张。这真的有损可读性，因为至少3个字符通常会给你至少一个元音。就我个人而言，我尝试使用至少5个字符。
2)我有一个恼怒的地方是以类结尾的类名(例如：personclass或buttonclass)，因为它可以消除你在做一个对象，而不是一个类的事实。做一个类的实例，类似的，我觉得可以(例如：蓝按钮，红标签)，因为它更容易阅读，但类的事情会变得非常烦人。
这个
那总是个坏主意。
所有关于如何编写不可维护代码的建议。
列出不好的想法可能需要一段时间，就在我的头顶上，我可以想到很多不好的名字：读者、作家、工厂、物品、计时器、接收者、发送者等等。
基本上，避免使用没有上下文的名称来表示类是什么或者它在更大范围中的角色。它不一定要像
任何可能覆盖标准类(EX:EDCOX1，3)，EDCOX1，4，and，C，在Java中)，除非你理解并特别打算引起这种行为。
摘要模板模型工厂对象
这些都是真正通用的，从类定义上看，它们中的一些可能是显而易见的。在一小段文档中，其他的显然会得到更好的注意(简单的参考是喜欢Resharper的一个原因)