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

现在考虑应用的布局:

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

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

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

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

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

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

我坚持基本的:VerbNoun(参数)。例子:GetDoc (docID)。

没有必要太花哨。一年后，不管是你还是其他人，都很容易理解。

Steve Mcconnell的《Code Complete》一书中有一个关于命名变量/类/函数/…

简而言之: 我同意好名字很重要，但我不认为你必须不惜一切代价在实现之前找到它们。

当然，最好一开始就有个好名字。但如果你不能在2分钟内想出一个，以后重命名将花费更少的时间，从生产力的角度来看是正确的选择。

长: 一般来说，在实现之前对名称考虑太久通常是不值得的。如果你实现你的类，命名它为“Foo”或“Dsnfdkgx”，在实现的时候，你会看到你应该给它命名什么。

特别是在Java+Eclipse中，重命名一点也不麻烦，因为它会小心地处理所有类中的所有引用，并警告您名称冲突等。只要这个类还没有在版本控制存储库中，我不认为重命名5次有什么错。

基本上，这是一个如何思考重构的问题。就我个人而言，我喜欢它，尽管它有时会惹恼我的队友，因为他们相信永远不要碰一个运行系统。从您可以重构的所有内容来看，更改名称是您可以做的最无害的事情之一。

当每个合理的名字看起来都太长或不明确时，你可以尝试使用一些不太合理的名字，例如:

类GoForHelpLassie 类DunnoAskTechSupport RTFVM类[V为Vendor]

确保名称是唯一的，并且在类的顶部有一个描述性注释，因为任何在代码中看到它的人都需要查找它来找出它是做什么的(但是当他们这样做时，他们可能会发现它更容易记住)。