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

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

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

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

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

具体到C#，我发现“框架设计指南：可重用.NET库的惯例、习语和模式”中有很多关于命名逻辑的好信息。

至于寻找那些更具体的单词，我经常使用同义词库，并在相关单词之间跳跃，试图找到一个好单词。不过，我尽量不花太多时间，随着开发的进展，我想出了更好的名称，或者有时意识到SuchAndSuchManager真的应该被分解为多个类，然后那个被弃用的类的名称就不再是问题了。

如果我不能为我的类找到一个比XyzManager更具体的名称，这将是我重新考虑这是否真的是属于一个类的功能，即架构“代码气味”的一点。

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

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

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

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

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

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