我学到的一个教训是，如果你找不到一个类的名字，那么这个类几乎总是有问题:

你不需要它 它做的太多了

这很困难，这是好事。它迫使你思考这个问题，以及这门课实际上应该做什么。好的名字有助于产生好的设计。

不要忘记设计模式(不仅仅是GoF模式)是一种提供公共词汇表的好方法，只要适合情况，就应该使用它们的名称。这甚至可以帮助熟悉命名法的新手快速理解体系结构。您正在处理的这个类是否应该充当Proxy，甚至是Façade ?

为什么不叫HelpDocumentServiceClient有点拗口，或者叫HelpDocumentClient…它是供应商并不重要，重要的是它是处理帮助文档的web服务的客户端。

是的，命名很难。

你用来描述问题的语言，就是你应该用来描述变量、方法、对象、类等的语言。一般来说，名词匹配对象，动词匹配方法。如果您缺少描述问题的词语，那么您也缺少对问题的全面理解(规范)。

如果它只是在一组名称中进行选择，那么它应该由您用来构建系统的约定来驱动。如果您遇到了以前的约定所没有发现的新情况，那么总是值得花一些精力尝试扩展它们(适当地、一致地)来覆盖这个新情况。

如果有疑问，那就睡一觉，选一个最明显的名字，第二天早上:-)

如果有一天你醒来发现自己错了，那就马上改变。

保罗。

BTW: Document.fetch()是非常明显的。

我发现局部变量最麻烦。例如，我想创建一个DocGetter类型的对象。我知道它是DocGetter。为什么我要给它另一个名字?我通常会给它起一个像dg(用于DocGetter)或temp之类的名字，或者其他同样没有描述性的名字。