同意了。我喜欢让我的类型名称和变量尽可能具有描述性，而不太长，但有时只是有一个特定的概念，你找不到一个好的词来形容。

在这种情况下，向同事寻求帮助总是有帮助的——即使他们最终没有帮助，它通常至少能帮助我大声解释出来，让我的车轮转动起来。

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

现在考虑应用的布局:

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

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

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

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

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

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

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

在“一个词”中总结方法/类，回答它的意思是什么? 这个词应该没有对应的词。

不是真的。考虑到在编码中必须理解的所有困难，说命名类和方法是编程中最困难的事情之一是荒谬的。不要误解我的意思，有时很难想出一个好名字，但让我们现实一点。我可以说这是编程中最简单的部分之一。

我所做的就是检查它是否太长如果我不记得它太长