命名类 | 易学教程

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>>

很久以前我读过一篇文章（我相信一篇博客文章），它让我在命名对象的“正确”轨道上：非常谨慎地命名程序中的东西。

例如，如果我的应用程序是（作为一个典型的业务应用程序）处理的用户，公司和地址，我有一个User ，一个Company和一个Address域类-也许某处UserManager ，一个CompanyManager和AddressManager会弹出一个手柄那些事。

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

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

或者， UserManager的工作可能是检查每个User对象的数据并以加密方式对数据进行签名。然后我们有一个UserRecordsClerk 。

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

我可以描述这些类的功能和（只要我不进入快速和脏的编码）我写的类只做一件事。我想念从名称到名称的是一种名称目录，一种将概念映射到名称的词汇表。

最终，我想在我的脑海里有类似图案目录的东西（通常设计图案很容易提供对象名称，例如工厂）

Factory - 创建其他对象（从设计模式中获取命名）
牧羊人 - 牧羊人处理物体的生命，它们的创建和关闭
同步器 - 在两个或多个对象（或对象层次结构）之间复制数据
保姆 - 帮助对象在创建后达到“可用”状态 - 例如通过连接到其他对象
等等

那么，你如何处理这个问题呢？你有一个固定的词汇表，你是否动态发明新的名字，或者你认为命名的东西不是那么重要或错误？

PS：我也对链接到讨论这个问题的文章和博客感兴趣。首先，这是让我思考它的原始文章：在没有“经理”的情况下命名Java类

更新：答案摘要

以下是我在此期间从这个问题中学到的内容的一些总结。

尽量不要创造新的比喻（保姆）
看看其他框架做了什么

关于这个主题的进一步文章/书籍：

以及我从答案中收集的主观名称前缀/后缀的当前列表：

协调员
生成器
作家
读者
处理器
容器
协议
目标
变流器
调节器
视图
厂
实体
桶

这条道路的好建议：

不要命名瘫痪。是的，名字非常重要，但它们不足以浪费大量时间。如果你不能在10分钟内想出一个好名字，继续前进。

#1楼

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

前20名是：

属性
类型
帮手
采集
变流器
处理器
信息
提供商
例外
服务
元件
经理
节点
选项
厂
上下文
项目
设计师
基础
编辑

#2楼

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

#3楼

与GOF书中所定义的模式相关，以及在这些模式之后命名对象在命名类，组织它们和传达意图方面有很长的路要走。大多数人会理解这种命名法（或至少是其中的一个主要部分）。

#4楼

我认为这里的关键是在代码的可见性范围内保持一致，即只要每个需要查看/处理代码的人都理解你的命名约定那么即使你决定调用它们也应该没问题。 'CompanyThingamabob'和'UserDoohickey'。如果您在公司工作，第一站是查看公司是否有命名约定。如果没有或者您不为公司工作，那么使用对您有意义的术语创建您自己的术语，将其传递给几个随意编码的可信赖的同事/朋友，并合并任何有意义的反馈。

应用其他人的惯例，即使它被广泛接受，如果它没有跳出你的页面，那么我的书中有点错误。首先，我需要在不参考其他文档的情况下理解我的代码，但同时它需要足够通用，以至于同一行业中同一领域的其他人都无法理解。