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

实现特定设计模式的类可以根据已知的模式名称(例如foofactory、foofacade)命名，而直接为域概念建模的类可以从问题域中取其名称，但是其他类呢？当我缺乏灵感，想要避免使用通用类名(如foohandler、fooprocessor、fooutils和foomanager)时，是否有类似于程序员同义词库的东西可以使用？

我将引用KentBeck的实现模式中的一些段落：

"[...] 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.

更详细的讨论，买这本书！这是值得的！：)

总是选择myclassa，myclassb-它允许一个很好的alpha排序。

我在开玩笑！

这是一个很好的问题，也是我不久前经历的一些事情。我在工作中对代码库进行了重新组织，在放置什么和调用什么方面遇到了问题。

真正的问题？

我上课做的太多了。如果你坚持单一的责任原则，一切都会变得更好。您可以将它分解为pagehandler、pageformatter(等等)，而不是一个整体的printhandler类，然后拥有一个主打印机类，它将所有内容组合在一起。

在我的重新组织中，这花了我很多时间，但是我最终放弃了很多重复的代码，使我的代码库更加合乎逻辑，并且在将一个额外的方法投入到类中之前，我学到了很多东西：d

但是，我不建议将模式名之类的东西放入类名中。类接口应该很明显(比如隐藏单例的构造函数)。如果类是为通用目的服务的，那么通用名称没有任何错误。

祝你好运！

乔希·布洛赫(Josh Bloch)关于良好的API设计的精彩演讲中有几点建议：

• 课程应该做一件事并且做得很好。
• 如果一个类很难命名或解释，那么它可能没有遵循前面要点中的建议。
• 类名应该立即传递类是什么。
• 好的名字有好的设计。

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

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

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

如果你坚持一个名字，有时仅仅给它一个半知半解的名字，承诺以后再修改它是一个很好的策略。

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

如果一个好的名字没有出现在我的脑海中，我可能会质疑是否存在更深层次的问题——这门课是否有一个好的目的？如果是，命名应该非常简单。

如果你的"fooprocessor"真的处理foos，那么不要因为你已经有了barprocessor、bazprocessor等而不愿意给它取这个名字。当有疑问时，显然是最好的。其他必须阅读代码的开发人员可能没有使用与您相同的同义词库。

也就是说，对于这个特定的例子，更具体的情况不会受到伤害。""过程"是一个相当宽泛的词。例如，它真的是一个"fooupdateprocessor"(可能会变成"fooupdater")吗？你不必对命名太"有创意"，但是如果你写了代码，你可能对它的作用和不作用有了相当好的了解。

最后，请记住，裸类名并不是您和代码的读者都必须继续使用的东西——通常也有名称空间在起作用。这些通常可以为读者提供足够的上下文，以便清楚地了解类的真正用途，即使它的裸名称是相当通用的。