有时候，一个类或方法没有一个好名字，我们都会遇到这种情况。然而，通常情况下，无法想出一个名称可能暗示您的设计存在问题。你的方法是否有太多的责任?你的类是否封装了一个连贯的想法?

不仅仅是命名一个类，创建一个适当的包结构可能是一个困难但有益的挑战。您需要考虑分离模块的关注点，以及它们与应用程序愿景的关系。

现在考虑应用的布局:

应用程序 VendorDocRequester(从web服务读取并提供数据) VendorDocViewer(使用请求程序提供供应商文档)

我冒昧地猜测，在一些课程中发生了很多事情。如果你将其重构为一种更加mvc化的方法，并允许小类处理单独的任务，你可能会得到如下结果:

应用程序 VendorDocs 模型 文档(保存数据的普通对象) WebServiceConsumer(处理web服务中的细节) 控制器 DatabaseAdapter(使用ORM或其他方法处理持久化) WebServiceAdapter(利用Consumer抓取文档并将其插入数据库) 视图 HelpViewer(使用DBAdapter输出文档)

然后，类名依赖于名称空间来提供完整的上下文。类本身可以固有地与应用程序相关，而不需要显式地这样说。因此，类名更简单，更容易定义!

另一个非常重要的建议:请帮自己一个忙，拿起一本《Head First Design Patterns》。这是一本非常棒的，易于阅读的书，将帮助您组织应用程序并编写更好的代码。欣赏设计模式将帮助您理解您遇到的许多问题已经得到解决，并且您将能够将解决方案合并到您的代码中。

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

DocumentFetcher吗?没有上下文很难说。

它可以帮助你像数学家一样，在你的领域中借用/发明一个词汇:使用简短的简单的词来暗示概念，而不是每次都拼写出来。我经常看到长拉丁短语变成首字母缩略词，让你需要一本字典来了解这些首字母缩略词。

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

在编程时，我也花了很多时间担心任何可以命名的东西的名称。不过我得说这很值得。有时，当我陷入困境时，我会把它放在一边，在喝咖啡休息的时候，我会问问周围的人是否有好的建议。

对于你的课程，我建议VendorHelpDocRequester。