为类提供良好，准确的名称是非常困难的。如果做得好，它会使代码更加自我记录，并提供一个词汇表来推断更高抽象级别的代码。
实现特定设计模式的类可能会根据众所周知的模式名称（例如FooFactory，FooFacade）给出一个名称，而直接模拟域概念的类可以从问题域中获取它们的名称，但是其他类的名称呢？ ？当我缺乏灵感，并且想避免使用泛型类名（如FooHandler，FooProcessor，FooUtils和FooManager）时，有什么类似程序员的词库可以转向吗？
答案 0 :(得分：56)
我将引用肯特贝克Implementation Patterns的一些段落：
“[...]名字应该简短而有力。 但是，要使名称准确 有时似乎需要几个 话。摆脱这种困境的方法是 选择一个强有力的比喻 计算。记住一个比喻， 甚至单个词带来了他们 丰富的协会网络，联系， 和影响。例如，在 HotDraw绘图框架，我的第一个 图形中对象的名称是 的 DrawingObject 即可。沃德坎宁安来了 以及排版比喻：a 绘画就像一个印刷的，布局的 页。页面上的图形项目是 数字，所以课程变得图。 在比喻的背景下，图 同时更短，更丰富，更好 比 DrawingObject 更精确。“
“子类的名称有两个作业。 他们需要沟通什么课 他们是这样的，他们是怎样的 不同。 [...]不同于 层次结构的根源，子类 几乎没有经常使用名称 谈话，所以他们可以 以存在为代价表达 简洁。 [...]
提供充当的子类 层次结构的根源本身就很简单 名。例如， HotDraw 有一个 类句柄，表示图 - 数字时的编辑操作 选择。简称为句柄 尽管扩展了图。有 一整套手柄和他们 最合适的名字就像 StretchyHandle 和 TransparencyHandle 。 因为句柄是它自己的根 层次结构，它应该很简单 超类名称超过合格 子类名称。
另一个皱纹 子类命名是多级的 层次结构。 [...]而不是盲目的 将修饰符添加到立即数 超类，想想来自的名字 读者的观点。什么级别 他需要知道这门课吗？ 喜欢？使用该超类作为基础 对于子类名称。“
两种命名界面风格取决于您对接口的看法。 作为没有实现的类的接口应该被命名为它们是类 （简单超类名称，合格子类名称）。这种风格的一个问题 命名是在命名类之前用完了好名字。一个 名为文件的接口需要一个名为的实现类 ActualFile ， ConcreteFile ，或者（yuck！） FileImpl （后缀和后缀） 缩写）。一般来说，沟通是否正在处理具体或 抽象对象很重要，抽象对象是否实现为 接口或超类不太重要。推迟区分 接口和超类很好地受到这种命名方式的支持，让你离开 如果有必要，可以在以后随意改变主意。
有时候，简单地命名具体课程对于沟通而言更重要 隐藏接口的使用。在这种情况下，前缀接口名称为“I”。如果 界面称为 IFile ，该类可以简单地称为文件。
有关详细讨论，请购买本书！这很值得！ ：）
答案 1 :(得分：37)
总是去MyClassA，MyClassB - 它允许一个不错的alpha排序..
我在开玩笑！
这是一个很好的问题，也是我不久前经历过的事情。我在工作中重组了我的代码库，并且遇到了什么问题以及把它称为什么......
真实问题？
我的课程做得太多了。如果你试图坚持single responsibility principle它会让所有东西都变得更好......而不是一个单片 PrintHandler 类，你可以把它分解成 PageHandler ， PageFormatter （依此类推）然后有一个主打印机类，它将所有这些组合在一起。
在我的重组中，花了我一些时间，但我最终将大量重复代码分类，让我的代码库更加合理，并且在进行思考之前学到了很多东西，然后再添加一个额外的方法class：D
我会不但是建议将类似名称的内容放入类名中。类接口应该显而易见（比如隐藏单例的构造函数）。如果该类服务于通用目的，则通用名称没有任何问题。
祝你好运！答案 2 :(得分：27)
Josh Bloch关于good API design的精彩演讲有一些很好的建议：
如果您的问题是为暴露的内部类命名的话，也许您应该将它们合并为更大的类。
如果你的问题是命名一个做很多不同东西的类，你应该考虑把它分成多个类。
如果这对公共API有好的建议，那么对任何其他类都不会有任何影响。
答案 3 :(得分：12)
如果你坚持使用一个名字，有时只是给它any一半明智的名字并承诺稍后修改它是一个很好的策略。
不要命名瘫痪。是的，名字非常重要，但它们不足以浪费大量时间。如果你在10分钟内想不出一个好名字，继续前进。
答案 4 :(得分：7)
如果一个好名字不会浮现在脑海中，我可能会质疑是否存在更深层次的问题 - 这个课程是否有用？如果是，则命名它应该非常简单。
答案 5 :(得分：2)
如果你的“FooProcessor”确实处理了foos，那么就不要因为你已经拥有BarProcessor，BazProcessor等而不愿意给它这个名字。如果有疑问，显然是最好的。其他必须阅读您的代码的开发人员可能没有使用相同的同义词库。
也就是说，对于这个特定的例子，更具特异性不会受到伤害。 “过程”是一个相当广泛的词。例如，它真的是一个“FooUpdateProcessor”（可能会成为“FooUpdater”）吗？你不必对命名过于“创造性”，但是如果你编写了代码，你可能对它的作用和不做的事情有了很好的了解。
最后，请记住，裸露的类名并不是您和代码的读者必须继续进行的 - 通常还有名称空间。那些通常可以给读者提供足够的上下文，以便清楚地看到你的课程是否真的适用，即使它的名字是相当通用的。