很久以前，我读过一篇文章（我相信是一篇博客文章），这篇文章让我在命名对象方面走上了“正确”的道路：对程序中的事物命名要非常谨慎。

例如，如果我的应用程序（作为一个典型的商业应用程序）处理用户、公司和地址，我会有一个User、一个Company和一个Address域类，并且可能会在某个地方弹出一个UserManager、一个CompanyManager和一个AddressManager来处理这些事情。

那么你能告诉那些UserManager、CompanyManager和AddressManager做什么吗？不，因为Manager是一个非常通用的术语，适用于您可以对域对象执行的任何操作。

我读到的文章建议使用非常具体的名称。如果它是一个C++应用程序，而UserManager的任务是分配用户并将其从堆中释放出来，那么它不会管理用户，而是保护用户的出生和死亡。嗯，也许我们可以称之为UserShepherd。

或者UserManager的工作是检查每个User对象的数据并对数据进行加密签名。然后我们会有一个UserRecordsClerk。

现在这个想法一直困扰着我，我试着去应用它。我发现这个简单的想法非常难。

我可以描述这些类做什么，（只要我不陷入快速和肮脏的编码）我编写的类只做一件事。我错过了从描述到名称的一种名称目录，一种将概念映射到名称的词汇表。

最终，我想在脑海中有一个类似于模式目录的东西（通常设计模式很容易提供对象名称，例如工厂）

Factory-创建其他对象（命名取自设计模式）牧羊人-牧羊人处理对象的生命周期、创建和关闭同步器-在两个或多个对象（或对象层次结构）之间复制数据保姆-帮助对象在创建后达到“可用”状态，例如通过连接到其他对象等等。

那么，你如何处理这个问题？你有固定的词汇表吗？你是临时发明新的名字吗？还是你认为给不那么重要或错误的东西命名？

注：我还对讨论这个问题的文章和博客的链接感兴趣。首先，这是一篇让我思考的原创文章：在没有“管理器”的情况下命名Java类

更新：答案摘要

下面是我从这个问题中学到的一点总结。

尽量不要制造新的隐喻（保姆）看看其他框架做什么

关于此主题的更多文章/书籍：

你发现自己经常在课前加上什么名字？命名类的最佳方法是什么？书：设计模式：可重用面向对象软件的元素（精装本）书：企业应用程序架构的模式（精装本）书：实现模式（平装）

以及我（主观地）从答案中收集的当前名称前缀/后缀列表：

协调员建设者作家读者处理程序容器协议目标转换器控制器看法工厂实体水桶

还有一个很好的建议：

不要陷入命名麻痹。是的，名字很重要，但它们不够重要，不足以浪费大量时间。如果你不能在10分钟内想出一个好名字，那就继续吧。