众所周知，要为班级提供好而精确的名称是非常困难的。如果做得正确，它将使代码更具自记录性，并为在更高抽象级别上进行代码推理提供了词汇。

可以基于众所周知的模式名称(例如FooFactory，FooFacade)为实现特定设计模式的类命名，而直接为领域概念建模的类可以从问题域中获取其名称，但是其他类呢？当我缺乏灵感并且想要避免使用通用类名(例如FooHandler，FooProcessor，FooUtils和FooManager)时，是否可以找到类似于程序员词库的东西？

解决方案

回答

如果没有想到一个好名字，我可能会问，是否存在一个更深层的问题，该课程是否起到了很好的作用？如果是这样，则命名应该非常简单。

回答

始终选择MyClassA，MyClassB，它允许进行很好的alpha排序。

我在开玩笑！

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

真正的问题？

我的课做得太多。如果我们尝试遵循单一职责原则，它将使所有内容都变得更好。.除了一个整体的PrintHandler类，我们可以将其分解为PageHandler，PageFormatter(等等)，然后拥有一个主Printer类将所有内容整合在一起。

在我的组织中，这花了我一些时间，但是我最终对很多重复的代码进行了分箱，使我的代码库更加逻辑化，并且在将额外的方法扔到类上之前，在思考方面学到了很多东西：D

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

祝你好运！

回答

如果我们坚持使用名称，有时只是给它一个半明智的名称并承诺以后再修改它是一个不错的策略。

不要让命名麻痹。是的，名称很重要，但它们的重要性还不足以浪费大量时间。如果我们不能在10分钟内想到一个好名字，那就继续吧。

回答

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

就是说，对于这个特定的例子，更多的特异性不会受到损害。 "过程"是一个相当宽泛的词。例如，它真的是" FooUpdateProcessor"(可能会变成" FooUpdater")吗？我们不必对命名有太多的"创意"，但是如果我们编写了代码，则可能对它的作用和不作用有一个很好的了解。

最后，请记住，裸类名称不仅是我们所需要的，而且代码读者也必须继续这样做，通常还需要使用名称空间。这些通常可以为读者提供足够的上下文，以便清楚地了解课程的真正目的，即使其裸名是相当通用的。

回答

我会引用肯特·贝克(Kent Beck)的《实现模式》中的一些段落：

简单的超类名称

"[...] The names should be short and punchy.
  However, to make the names precise
  sometimes seems to require several
  words. A way out of this dilemma is
  picking a strong metaphor for the
  computation. With a metaphor in mind,
  even single words bring with them a
  rich web of associations, connections,
  and implications. For example, in the
  HotDraw drawing framework, my first
  name for an object in a drawing was
  DrawingObject. Ward Cunningham came
  along with the typography metaphor: a
  drawing is like a printed, laid-out
  page. Graphical items on a page are
  figures, so the class became Figure.
  In the context of the metaphor, Figure
  is simultaneously shorter, richer, and
  more precise than DrawingObject."

合格的子类名称

"The names of subclasses have two jobs.
  They need to communicate what class
  they are like and how they are
  different. [...] Unlike the names at
  the roots of hierarchies, subclass
  names aren’t used nearly as often in
  conversation, so they can be
  expressive at the cost of being
  concise. [...]
  
  Give subclasses that serve as the
  roots of hierarchies their own simple
  names. For example, HotDraw has a
  class Handle which presents figure-
  editing operations when a figure is
  selected. It is called, simply, Handle
  in spite of extending Figure. There is
  a whole family of handles and they
  most appropriately have names like
  StretchyHandle and TransparencyHandle.
  Because Handle is the root of its own
  hierarchy, it deserves a simple
  superclass name more than a qualified
  subclass name. 
  
  Another wrinkle in
  subclass naming is multiple-level
  hierarchies. [...] Rather than blindly
  prepend the modifiers to the immediate
  superclass, think about the name from
  the reader’s perspective. What class
  does he need to know this class is
  like? Use that superclass as the basis
  for the subclass name."

界面

Two styles of naming interfaces depend on how you are thinking of the interfaces. 
  Interfaces as classes without implementations should be named as if they were classes 
  (Simple Superclass Name, Qualified Subclass Name). One problem with this style of 
  naming is that the good names are used up before you get to naming classes. An 
  interface called File needs an implementation class called something like 
  ActualFile, ConcreteFile, or (yuck!) FileImpl (both a suffix and an 
  abbreviation). In general, communicating whether one is dealing with a concrete or 
  abstract object is important, whether the abstract object is implemented as an 
  interface or a superclass is less important. Deferring the distinction between 
  interfaces and superclasses is well >supported by this style of naming, leaving you 
  free to change your mind later if that >becomes necessary.
  
  Sometimes, naming concrete classes simply is more important to communication than 
  hiding the use of interfaces. In this case, prefix interface names with “I”. If the 
  interface is called IFile, the class can be simply called File.

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

回答

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

• 班级应该做一件事并且做得很好。
• 如果一个班级很难命名或者解释，那么它可能不遵循上一个要点的建议。
• 班级名称应立即传达班级的含义。
• 好的名字驱动好的设计。

如果问题是要公开内部类的名字，也许我们应该将它们合并为一个更大的类。

如果问题是命名一个执行许多不同工作的类，则应考虑将其分为多个类。

如果这对于公共API来说是个好建议，那么对于其他任何类都不会受到伤害。