99

为类想出好的、精确的名称是出了名的困难。做得对，它使代码更加自文档化，并为在更高抽象级别上推理代码提供了一个词汇表。

实现特定设计模式的类可能会根据众所周知的模式名称（例如 FooFactory、FooFacade）来命名，而直接建模领域概念的类可以从问题域中取名，但是其他类呢？当我缺乏灵感并想避免使用通用类名（如 FooHandler、FooProcessor、FooUtils 和 FooManager）时，是否有类似程序员词库之类的东西可以求助？

4

6 回答 6

64

我将引用Kent Beck的实施模式中的一些段落：

简单的超类名称

“[...] 名称应该简短而有力。然而，为了使名称准确有时似乎需要几个词。摆脱这种困境的方法是为计算选择一个强有力的隐喻。考虑到隐喻，即使单个单词带来了丰富的关联、连接和含义网络。例如，在 HotDraw 绘图框架中，我对绘图中的对象的第一个名称是 DrawingObject。Ward Cunningham 出现了排版隐喻：绘图就像“ _ _ _ _ _ _

合格的子类名称

“子类的名称有两个工作。他们需要传达他们喜欢什么类以及它们有何不同。[...] 与层次结构根部的名称不同，子类名称在对话中几乎没有经常使用，因此它们可以以简洁为代价来表达。 [...]

为作为层次结构根的子类提供自己的简单名称。例如，HotDraw有一个Handle类，它在选择图形时呈现图形编辑操作。 尽管扩展了Figure ，但它被简单地称为Handle。有一整套句柄，它们最恰当的名称是 StretchyHandle和TransparencyHandle。因为Handle是其自身层次结构的根，所以它应该有一个简单的超类名称，而不是一个合格的子类名称。

子类命名的另一个问题是多级层次结构。[...]与其盲目地将修饰符添加到直接超类，不如从读者的角度考虑名称。他需要知道这门课是什么样的课？使用该超类作为子类名称的基础。”

界面

两种命名接口的风格取决于您对接口的看法。作为没有实现的类的接口应该像类一样命名（简单超类名称、合格子类名称）。这种命名风格的一个问题是，好名字在你命名类之前就用完了。一个名为File的接口需要一个名为 ActualFile、ConcreteFile或（糟糕！）FileImpl之类的实现类（后缀和缩写）。一般来说，沟通是处理具体对象还是抽象对象很重要，抽象对象是实现为接口还是超类并不重要。这种命名风格很好地支持了推迟接口和超类之间的区别，让您在以后有必要时可以自由地改变主意。

有时，简单地命名具体类比隐藏接口的使用更重要。在这种情况下，请在接口名称前加上“I”。如果接口称为IFile，则该类可以简单地称为File。

如需更详细的讨论，请购买本书！这很值得！:)

于 2008-09-07T01:05:59.813 回答
40

总是选择 MyClassA，MyClassB - 它允许一个很好的 alpha 排序..

我在开玩笑！

这是一个很好的问题，也是我不久前经历的。我在工作中重新组织我的代码库，并且遇到了在哪里放置什么以及如何称呼它的问题。

真正的问题？

我的课做得太多了。如果您尝试遵守单一职责原则，它将使所有内容都更好地结合在一起。.而不是一个单一的 PrintHandler类，您可以将其分解为PageHandler，PageFormatter（等等），然后拥有一个主打印机类将这一切结合在一起。

在我的重组中，我花了一些时间，但最终我合并了很多重复的代码，让我的代码库更加合乎逻辑，并且在思考之前在课堂上抛出一个额外的方法时学到了很多东西：D

但是，我不建议将模式名称之类的内容放入类名中。类接口应该使这一点显而易见（例如隐藏单例的构造函数）。如果该类用于通用目的，则通用名称没有任何问题。

祝你好运！

于 2008-09-01T15:16:21.413 回答
29

Josh Bloch 关于良好 API 设计的精彩演讲有一些很好的建议：

  • 班级应该做一件事并做好。
  • 如果一个类很难命名或解释，那么它可能没有遵循上一个要点中的建议。
  • 类名应该立即传达类是什么。
  • 好的名字驱动好的设计。

如果您的问题是如何命名公开的内部类，也许您应该将它们合并到一个更大的类中。

如果你的问题是命名一个做很多不同事情的类，你应该考虑把它分成多个类。

如果这对公共 API 来说是个好建议，那么它不会对任何其他类造成伤害。

于 2008-09-07T01:41:57.793 回答
14

如果你被一个名字困住了，有时只是给它一个半明智的名字，并承诺以后修改它是一个很好的策略。

不要命名瘫痪。是的，名字很重要，但还不足以浪费大量时间。如果你不能在 10 分钟内想出一个好名字，那就继续吧。

于 2008-09-01T15:20:13.510 回答
10

如果没有想到一个好名字，我可能会质疑是否存在更深层次的问题——这个类是否有一个好的目的？如果是，命名它应该非常简单。

于 2008-09-01T15:12:00.970 回答
3

如果您的“FooProcessor”确实处理 foo，那么不要因为您已经拥有 BarProcessor、BazProcessor 等而不愿意给它起这个名字。如果有疑问，显而易见是最好的。必须阅读您的代码的其他开发人员可能不会使用与您相同的词库。

也就是说，对于这个特定的例子来说，更多的特异性不会受到伤害。“过程”是一个相当宽泛的词。例如，它真的是“FooUpdateProcessor”（可能变成“FooUpdater”）吗？您不必对命名过于“有创意”，但如果您编写了代码，您可能对它的作用和不作用有相当好的了解。

最后，请记住，纯类名并不是您和您的代码读者必须继续使用的全部内容 - 通常还有名称空间在起作用。这些通常可以为读者提供足够的上下文来清楚地了解您的课程的真正用途，即使它的裸名相当通用。

于 2008-09-01T16:08:49.540 回答