命名类-如何避免将所有内容都称为“ <WhatEver> Manager”？

Question

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

例如，如果我的应用程序（作为典型的业务应用程序）正在处理用户，公司和地址，则我将具有User，a Company和Address域类-可能会弹出a UserManager，a CompanyManager和a AddressManager来处理这些问题。

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

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

或者，也许UserManager的工作是检查每个User对象的数据并用密码对数据签名。然后我们会有一个UserRecordsClerk。

现在，这个想法一直困扰着我，我尝试应用它。并且很难找到这个简单的想法。

我可以描述这些类的作用，并且（只要我不会陷入快速而肮脏的编码中）我编写的类就是一件事。从描述到名称，我想念的是一种名称目录，这是一个将概念映射到名称的词汇表。

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

工厂-创建其他对象（取自设计模式的命名）

牧羊人-牧羊人处理对象的生命周期，对象的创建和关闭

同步器-在两个或多个对象（或对象层次结构）之间复制数据

保姆-帮助对象在创建后达到“可用”状态-例如通过连接到其他对象

等等等

那么，您如何处理该问题？您是否有固定的词汇表，是否在动态地发明新名称，或者您认为命名不那么重要或错误？

Answer 1

在可能的情况下，我尝试复制.NET框架中已经存在的名称，然后在Java和Android框架中寻找想法。似乎Helper，Manager和Util是您为协调类所附加的不可避免的名词，这些类不包含状态并且通常是过程性的和静态的。另一种选择是Coordinator。你可以得到与名字特别紫色prosey，去之类的东西Minder，Overseer，Supervisor，Administrator，和Master，但正如我所说，我更喜欢保持它就像你正在使用的框架名称。您还可以在.NET框架中找到一些其他常见的后缀（如果这是正确的术语）：BuilderWriterReaderHandlerContainer

Answer 2

我全都追求好名字，而且我经常写关于选择事物名称时要格外小心的重要性。出于同样的原因，在命名事物时，我也谨防隐喻。在最初的问题中，“工厂”和“同步器”看起来像是好名字。但是，“牧羊人”和“保姆”却不是，因为它们是基于隐喻的。您代码中的类实际上不能是一个保姆。您之所以称其为保姆，是因为它照顾其他事情，就像现实生活中的保姆照顾婴儿或孩子一样。在非正式演讲中这是可以的，但是（以我的观点）在代码中命名类（必须由谁知道谁知道谁来维护）是不好的。为什么？因为隐喻是与文化有关的，通常也与个人有关。对您来说，命名一个班级“保姆”可能很清楚，但对于其他人来说可能不太清楚。除非您编写的代码仅供个人使用，否则我们不应该依赖于此。在任何情况下，约定都可以构成或破坏一个隐喻。“工厂”本身的使用是基于一个隐喻，但是已经存在了一段时间了，并且在编程世界中目前是众所周知的，因此我可以说使用它是安全的。但是，“保姆”和“牧羊人”是不可接受的。