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

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

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

我认为最重要的一点是：这个名字足够描述性吗？你能通过看这个名字来判断这个班应该做什么吗？在类名中使用“Manager”、“Service”或“Handler”等词可能被认为过于通用，但由于许多程序员都使用它们，这也有助于理解类的用途。

我自己也一直在使用门面模式（至少，我认为这就是所谓的）。我可以有一个仅描述一个用户的User类，以及一个跟踪我的“用户集合”的Users类。我不把这个类称为UserManager，因为我不喜欢现实生活中的管理者，我不想被提醒：）简单地使用复数形式有助于我理解这个类的作用。

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

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

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

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

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

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

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

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