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

是的，命名很难。

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

这对我来说通常是很自然的。我总是创建非常短的方法，从不超过6行Smalltalk代码(自动格式化)，所以我说这个方法是关于什么的真的没有任何困难。

有时类名很困难，因为我想选择的单词在系统的某个地方正在使用，因为有时同一个单词在不同的上下文中有不同的含义。我希望在这些情况下，允许一些类似维基百科的语法，这样我就可以将我的类命名为“Task (To do list item)”。在这是合法的之前，我用了一个很大的德语风格的单词:ToDoListItemTask。您可能已经猜到了:我的方法名也可以很长。但我认为它们是可读的。

所以，在你的例子中，你的类是一个“getter”，或检索器，或其他什么。你确定这应该在课堂上模仿吗?难道供应商文档不应该请求自己吗?类似于vendorDoc.requestFrom(source);说出名字就容易多了，不是吗?

欢呼,

niko

如果这个名称可以向外行程序员解释清楚，那么可能就没有必要更改它。

我不得不承认命名是一门艺术。如果你的类遵循特定的“设计模式”(工厂等)，事情就会变得简单一些。

对我来说，我不在乎一个方法或类名有多长，只要它是描述性的，并且在正确的库中。应该记住API的每个部分驻留在哪里的日子已经一去不复返了。

智能感存在于所有主要语言中。因此，当使用第三方API时，我喜欢使用它对文档的智能感知，而不是使用“实际的”文档。

考虑到这一点，我可以创建一个方法名，如

StevesPostOnMethodNamesBeingLong或Short

很长，但那又怎样。现在谁不用24英寸的屏幕呢!