因此，我正在处理这个类，它应该通过web服务从供应商请求帮助文档。我试着把它命名为documententretriver, VendorDocRequester, DocGetter，但它们听起来不太对。最后，我在dictionary.com网站上浏览了半个小时，试图找到一个合适的词。
带着坏名字开始编程就像早上头发很糟一样，接下来的一天就会每况愈下。感觉我吗?
当前回答
有时候，一个类或方法没有一个好名字，我们都会遇到这种情况。然而，通常情况下，无法想出一个名称可能暗示您的设计存在问题。你的方法是否有太多的责任?你的类是否封装了一个连贯的想法?
其他回答
这很困难，这是好事。它迫使你思考这个问题，以及这门课实际上应该做什么。好的名字有助于产生好的设计。
有时候，一个类或方法没有一个好名字，我们都会遇到这种情况。然而，通常情况下，无法想出一个名称可能暗示您的设计存在问题。你的方法是否有太多的责任?你的类是否封装了一个连贯的想法?
不仅仅是命名一个类，创建一个适当的包结构可能是一个困难但有益的挑战。您需要考虑分离模块的关注点，以及它们与应用程序愿景的关系。
现在考虑应用的布局:
应用程序 VendorDocRequester(从web服务读取并提供数据) VendorDocViewer(使用请求程序提供供应商文档)
我冒昧地猜测，在一些课程中发生了很多事情。如果你将其重构为一种更加mvc化的方法，并允许小类处理单独的任务，你可能会得到如下结果:
应用程序 VendorDocs 模型 文档(保存数据的普通对象) WebServiceConsumer(处理web服务中的细节) 控制器 DatabaseAdapter(使用ORM或其他方法处理持久化) WebServiceAdapter(利用Consumer抓取文档并将其插入数据库) 视图 HelpViewer(使用DBAdapter输出文档)
然后，类名依赖于名称空间来提供完整的上下文。类本身可以固有地与应用程序相关，而不需要显式地这样说。因此，类名更简单，更容易定义!
另一个非常重要的建议:请帮自己一个忙，拿起一本《Head First Design Patterns》。这是一本非常棒的，易于阅读的书，将帮助您组织应用程序并编写更好的代码。欣赏设计模式将帮助您理解您遇到的许多问题已经得到解决，并且您将能够将解决方案合并到您的代码中。
你用来描述问题的语言，就是你应该用来描述变量、方法、对象、类等的语言。一般来说，名词匹配对象，动词匹配方法。如果您缺少描述问题的词语，那么您也缺少对问题的全面理解(规范)。
如果它只是在一组名称中进行选择，那么它应该由您用来构建系统的约定来驱动。如果您遇到了以前的约定所没有发现的新情况，那么总是值得花一些精力尝试扩展它们(适当地、一致地)来覆盖这个新情况。
如果有疑问，那就睡一觉，选一个最明显的名字，第二天早上:-)
如果有一天你醒来发现自己错了，那就马上改变。
保罗。
BTW: Document.fetch()是非常明显的。
我坚持基本的:VerbNoun(参数)。例子:GetDoc (docID)。
没有必要太花哨。一年后，不管是你还是其他人，都很容易理解。
