我问了一个类似的问题，但在可能的情况下，我尝试复制.NET框架中已有的名称，并在Java和Android框架中寻找想法。

看起来Helper、Manager和Util是协调类时不可避免的名词，这些类不包含状态，通常是过程性和静态的。另一种选择是协调员。

你可能会得到特别紫色的名字，并喜欢像Minder、Overser、Supervisor、Administrator和Master这样的东西，但正如我所说，我更喜欢保持它像你习惯的框架名称一样。

在.NET框架中还可以找到一些其他常用后缀（如果这是正确的术语）：

建设者使用某些参数构造特殊类型实例的类型。生成器通常是一次性的。它甚至可能不需要分配变量。如果类型需要重复创建对象，请使用Factory。如果负责创建多个不同类型对象的类型，请使用工厂。作家把一些变量写进一些东西。读者读一些变量。处理程序设计用于处理一种情况或其他事情。容器可以放些东西进去。

熟悉GOF书中定义的模式，并以此命名对象，这让我在命名类、组织类和传达意图方面有了很长的路。大多数人都会理解这个术语（或者至少是其中的一个主要部分）。

我都喜欢好名字，我经常写下在为事物取名字时要非常小心的重要性。出于同样的原因，我在命名事物时对隐喻持谨慎态度。在最初的问题中，“工厂”和“同步器”看起来像是它们的好名字。然而，“牧羊人”和“保姆”不是，因为它们是基于隐喻的。代码中的类不能是保姆；你称它为保姆，因为它照顾一些其他事情，就像现实生活中的保姆照顾婴儿或孩子一样。这在非正式演讲中是可以的，但在我看来，在代码中命名类是不可以的，因为这些类必须由谁知道谁知道什么时候维护。

为什么？因为隐喻依赖于文化，也常常依赖于个人。对你来说，给一个班级取名“保姆”可能很清楚，但对其他人来说可能不那么清楚。我们不应该依赖它，除非您编写的代码仅供个人使用。

在任何情况下，惯例都可以形成或打破隐喻。“工厂”本身的使用是基于一个隐喻，但这个隐喻已经存在了很长时间，目前在编程界相当知名，所以我想说使用它是安全的。然而，“保姆”和“牧羊人”是不可接受的。

你可以看看source-code-wordle.de，我已经在那里分析了.NET框架和其他一些库中最常用的类名后缀。

前20名是：

属性类型帮手收集转换器处理器信息供应商例外服务要素经理节点选项工厂上下文项目设计师基础编辑

当我发现自己正在考虑在类名中使用Manager或Helper时，我认为这是一种代码气味，这意味着我还没有找到正确的抽象，和/或我违反了单一责任原则，因此重构和在设计中投入更多的精力通常会使命名更加容易。

但即使是设计良好的类也不会（总是）命名，您的选择部分取决于您是创建业务模型类还是技术基础设施类。

业务模型类可能很难，因为它们对于每个领域都不同。我经常使用一些术语，如域内策略类的策略（例如，LateLrentalPolicy），但这些术语通常来自于尝试创建一种可以与业务用户共享的“无处不在的语言”，设计和命名类，以便它们模拟真实世界的想法、对象、动作和事件。

技术基础设施类稍微简单一些，因为它们描述了我们非常熟悉的领域。我更喜欢将设计模式名称合并到类名中，如InsertUserCommand、CustomerRepository或SapAdapter。我理解关于传达实现而不是意图的担忧，但设计模式结合了类设计的这两个方面——至少在处理基础设施时，即使在隐藏细节的同时，也希望实现设计透明。

我认为这里的关键是要在代码的可见性范围内保持一致，即，只要需要查看/处理代码的每个人都理解您的命名约定，那么这应该很好，即使您决定将其称为“CompanyThingamabob”和“UserDoohickey”。如果你在一家公司工作，第一步是看是否有公司命名的惯例。如果没有，或者你不为公司工作，那么就创建自己的、对你有意义的术语，将其传递给几个值得信任的同事/朋友，他们至少会随意编写代码，并结合任何有意义的反馈。

在我的书中，套用别人的惯例，即使它被广泛接受，如果它不从页面上跳出来攻击你，也是有点错误的。首先，我需要在不参考其他文档的情况下理解我的代码，但同时它需要足够通用，以使同一行业中同一领域的其他人无法理解。