很久以前，我读过一篇文章（我相信是博客文章），这使我走在命名对象的“正确”轨道上：在程序中命名事物时要非常谨慎。
例如，如果我的应用程序（作为典型的业务应用程序）正在处理用户，公司和地址，则我将具有User，a Company和Address域类-可能会弹出a UserManager，a CompanyManager和a AddressManager来处理这些问题。
所以，你可以告诉那些UserManager，CompanyManager和AddressManager做什么？不可以，因为Manager是一个非常通用的术语，适用于您可以使用域对象执行的所有操作。
我阅读的文章建议使用非常具体的名称。如果它是C ++应用程序，并且UserManager的工作是分配用户并将其从堆中释放出来，那么它将不会管理用户，而是保护用户的生死。嗯，也许我们可以将其称为UserShepherd。
或者，也许UserManager的工作是检查每个User对象的数据并用密码对数据签名。然后我们会有一个UserRecordsClerk。
现在，这个想法一直困扰着我，我尝试应用它。并且很难找到这个简单的想法。
我可以描述这些类的作用，并且（只要我不会陷入快速而肮脏的编码中）我编写的类就可以做一件事。从描述到名称，我想念的是一种名称目录，这是一个将概念映射到名称的词汇表。
最终，我想在脑海中想起一个模式目录（通常，设计模式很容易提供对象名称，例如工厂）
- 工厂-创建其他对象（取自设计模式的命名）
- 牧羊人-牧羊人处理对象的生命周期，对象的创建和关闭
- 同步器-在两个或多个对象（或对象层次结构）之间复制数据
保姆-帮助对象在创建后达到“可用”状态-例如，通过连接到其他对象
等等等
那么，您如何处理该问题？您是否有固定的词汇表，是否在动态地发明新名称，或者您认为命名不那么重要或错误？
PS：我也对讨论该问题的文章和博客链接感兴趣。首先，这是让我思考的原始文章：不带“ Manager”命名Java类
更新：答案摘要
这是我同时从这个问题中学到的一些小知识。
- 尽量不要创建新的隐喻（保姆）
- 看看其他框架做什么
有关此主题的其他文章/书籍：
还有我从答案中（主观地！）收集的名称前缀/后缀的当前列表：
- 协调员
- 建造者
- 作家
- 读者
- 处理程序
- 容器
- 协议
- 目标
- 转换器
- 控制者
- 视图
- 厂
- 实体
- 桶
道路上的一个好提示：
不要让命名麻痹。是的，名称很重要，但它们的重要性还不足以浪费大量时间。如果您不能在10分钟内想到一个好名字，那就继续吧。