软件方法（下）第8章分析之分析类图—知识篇Part07（202205更新）命名的词性和语言

可到此处下载《软件方法》（下）目前公开的最新pdf版本：

http://www.umlchina.com/book/softmeth2.pdf

8.2.4.5 命名的词性

类和属性应该用名词命名。例如，上文出现的类“人员”、“商品”、“姓名”等就是名词。

在汉语中，动词可以不做任何变化，直接作为名词使用。例如，“我的奋斗”、“嫌疑人X的献身”以及“面向对象设计”，其中的“奋斗”、“献身”和“设计”就是动词的名词化。

因此，“申请”、“审批”、“入库”、“出库”等同样可以作为类的名称。虽然它们看起来是动词，但在作为类的名称的时候，已经被当作名词了。

有的建模人员不理解这一点，总觉得看着不舒服，非得在后面加一个“单”、“记录”、“信息”、“事件”之类，变成“申请单”、“申请记录”、“申请信息”、“申请事件”。

其实并不需要，否则每个动词刷一个后缀，又变成废话刷工作量了。“事件”还说得过去，像“单”、“记录”、“信息”等后缀已经假设了其具体形态，就更不可取了。即使建模时面对的素材是一张纸质的申请单，类的名字也应该写“申请”，因为这才是本质的概念。

图8-67 “动词”直接作为类的名字，不用加后缀

如果一个用语在某个领域中已经存在很久，成为了该领域的术语，即使它看起来犯了以上提到的冗余错误，用来作为模型元素的命名也无妨。例如"订单"带有"单"字，实际上描述的是一次"购买"或“交易”，不过"订单"已经在领域中广泛使用，而且把“单”去掉留下“订”也不合适，所以“订单”可以作为类名。

在其他语言中，动词不一定能直接用作名词，可能要做一些变化。

在英语中，像“设计”是可以直接使用的：design→design，但像“献身”可能就要加一个词缀：devote→devotion。其他词缀可能还有ment、ance、ing、ness等。

*领域驱动设计话语中的“领域事件（Domain Event）”采用了动词的过去式来命名，例如OrderShipped，这是错误的。应该用名词命名，关于这方面的阐述，可参见我写的这篇文章>>*

因此，在汉语中，“支付”可以作为类的名称（名词），也可以作为操作的名称（动词），而在英语中，类的名称可能叫Payment，操作的名称叫Pay，如图8-68。

图8-68 汉语和英语的类名和操作名

以上说的是动词的名词化。

形容词也可以名词化，例如，“沉默是金”、“把悲伤留给自己”。

不过，在用作类和属性的名称时，形容词和动词不同。首先，形容词不会用作类的名称；其次，形容词用作属性名称时，也不会像动词一样直接把该形容词作为属性名称。

如果需要把一个形容词作为属性，目的必然是测量它的值。这种情况下，领域中往往已经有了另一个术语来专门描述测量值，例如：测量“重”，有“重量”，测量“浓”，有“浓度”。我们应该使用领域中已有的术语。

那如果领域知识中没有这个术语呢，需不需要软件开发人员造一个？例如，在形容词后面加个“值”、“度”、“指数”之类，“美”→“美丽度”或“颜值”，“高尚”→“高尚指数”？

不需要，也没资格。

如果领域知识中没有测量“美”的术语，说明这方面的领域知识可能还不存在，怎么可能会让软件开发人员在软件中封装这些知识呢？

如果涉众硬是需要软件开发人员在软件中封装这些知识，那么此时软件开发人员就不只是软件开发人员了，他要扮演两个角色：首先，他是一名研究“美”的学问的领域专家；其次，他是一名把某个领域专家的研究结果封装到软件中的软件开发人员。这两个角色可以由同一个人担任，也可以分开。

*同前文所述，此处的研究不一定是科学研究，也可以是修仙、漫威、哈利波特、王者荣耀。*

当形容词原样出现在类的属性中时，它是作为“状态属性”出现的。严格来说，“状态属性”并不是属性，要注意“状态属性”和上面提到的形容词测量值的区别。

如图8-69，“人”的“重”和“重量”不是一个概念。“重量”是属性，“重”是状态。状态应该用状态机描述，在领域逻辑上，状态“重”也许会仅由“重量”的属性值区间决定，也许会由更多属性的属性值区间决定，在实现上，状态“重”也许会如图8-69左侧实现为一个“重”的布尔类型“状态属性”，也许不会。

关于状态和状态机建模，后文再详述。

图8-69 状态属性和测量值

8.2.4.6 命名所用的语言

这里说的不是编程语言，而是汉语、英语、日语……

给核心域元素命名，使用的语言应该首先考虑精确体现核心域内涵和方便开发团队思考和交流核心域知识。该用汉语就用汉语，该用英语就用英语，该用日语就用日语。

以前经常会考虑转换到编程语言时需要改名的问题。在设计工作流，如果我们使用的编程语言只能用英语命名类、属性、操作等——更严谨的说法应该是编译器广泛支持的字符集比较小，那么还需要一个对编程语言合法的名字。

建模工具例如EA，一般会提供别名（Alias），真实名称用编译器支持的字符集，再加一个别名用于显示。

随着时代的发展，编译器、DBMS等支持的字符集越来越大，上面提到的问题慢慢不再是问题。如果团队成员更熟悉汉语，那么在代码中使用汉语命名即可，省去蹩脚英语或者模糊的汉语拼音缩写（啥？你说“可以加注释嘛”？）给后续工作带来的麻烦。

其他如在文本编辑器中时切换输入法太麻烦、版式不好看等问题，在图形建模时影响较小。

以上所说仅是针对目标系统的核心域元素的命名，不涉及非核心域部分。非核心域部分内容，和计算机和软件领域有关。这方面的“外语”，不管是计算机和软件专业的各个概念，还是编程语言的关键字，要求软件人员熟练掌握是理所应当的。

例如，浑元形意太极掌门马老师找我们为他的门派搞一套“修炼辅助系统”。作为软件开发人员，能认真去体会马老师说的“化劲”、“武德”、“真气”、“掌门”之类的概念就已经不易，还要把它们变成英语就更难为人了，估计马老师自己也不知道。

但是，作为软件开发人员，不知道什么叫DTO，什么叫Iterator就不应该了，因此，命名为“武德DTO”之类是没有问题的。

如果目标系统是面向国际的，那怎么办呢？还是前面说的，首先考虑精确体现核心域内涵和方便开发团队思考和交流核心域知识。该用汉语就用汉语，该用英语就用英语，该用日语就用日语。

8.2.4.7 类命名用单数

类的名称已经是一个抽象概念，既代表属于这个类的所有对象的集合，也指代集合中的任何一个对象。

例如，“人”这个概念既代表所有符合“人”的特征的对象的集合，我们可以说“人是一种动物”；同时，“人”可以代表“任何一个人的个体”，我们可以说“人有姓名、身高”。这两种用法，分别对应于后文要讲解的泛化和关联关系。

如果用复数表达，例如汉语“人们”，英语“people”，第二种用法就很别扭了，实例“某个人们”是什么？

图8-70 类命名用单数

如果“某个人们”另有含义，那么应该有另外一个类。例如，社区团购系统中，“某个顾客们”另有含义“团”，那么应该添加一个类“团”。

有一些常见的开发习惯，如数据库表名用复数，甚至有的框架在类转换表时，直接就在名称后面加上s，理由是表里有很多行。其实"类"、"表"的概念已经隐含了"多个对象"、"多行"的意思，不用再加了。而且，如果英语不熟，还得费心思去想正确的复数形式，何必呢？