第5章　类关系理论

5.1 提出背景

前一章已经建立了“类—对象结构关系”。

其基本结构为：

世界
↓
基础类
↓
对象实例
↓
属性
↓
状态
↓
关系
↓
场景

但是，当机器建立了大量基础类以后，一个新的问题立即出现：

这些类之间是什么关系？

例如：

动物类
↓
鸟类
↓
鸡类

这里存在父类与子类关系。

又例如：

汽车类
├── 发动机类
├── 车轮类
├── 车身类
└── 制动系统类

这里存在包含和组合关系。

再例如：

人类
↓ 使用
手机类

这里存在使用关系。

如果机器只能知道“有苹果类、锅类、鸡蛋类、人类、机械臂类”，却不知道这些类之间如何连接，那么这些知识仍然只是孤立的类别集合。

真正的世界知识必须具有结构：

类
↓
类关系
↓
类结构
↓
对象结构
↓
场景结构

因此，**类关系（Class Relationship）**是描述不同类之间结构联系的理论。

类关系不是对象本身，也不是对象的属性，而是对世界中类别结构之间连接方式的抽象描述。

5.2 类关系的定义

**类关系（Class Relationship）**是两个或多个类之间按照继承、包含、组成、关联、依赖、控制、使用等方式建立的结构联系。

可以抽象表示为：

ClassA → Relation → ClassB

其中：

ClassA 表示关系的起始类；
ClassB 表示关系的目标类；
Relation 表示两类之间的关系类型。

例如：

人类 → 使用 → 手机类

表示：

人类与手机类之间存在使用关系。

又如：

汽车类 → 包含 → 发动机类

表示：

汽车结构中包含发动机结构。

再如：

动物类 → 继承 → 鸟类

表示：

鸟类属于动物类的下位类别。

因此，类关系的核心作用是：

把孤立的类组织成具有方向、层次、结构和功能意义的机器世界知识网络。

5.3 类关系的基本分类

类关系可以划分为不同结构类型：

类关系
├── 继承关系
├── 兄弟关系
├── 包含关系
├── 组合关系
├── 关联关系
├── 依赖关系
├── 控制关系
└── 使用关系

这些关系虽然都表现为“类与类之间的连接”，但是它们表达的语义完全不同。

因此不能把所有关系简单定义为：

ClassA → ClassB

而应该进一步确定：

ClassA
↓
RelationType
↓
ClassB

其中 RelationType 决定机器应该如何理解这两个类之间的结构。

5.4 父类与子类

**父类（Parent Class）**是具有较一般结构的类。

**子类（Child Class）**是在父类结构基础上进一步限定或扩展的类。

二者形成继承关系：

父类
↓
子类

例如：

动物类
↓
鸟类
↓
鸡类

这里：

动物类 = 父类
鸟类 = 动物类的子类
鸡类 = 鸟类的子类

继承关系形成类别层级。

可以表示为：

ChildClass ⊂ ParentClass

其中：

ChildClass 表示子类；
ParentClass 表示父类；
⊂ 表示子类属于父类结构范围中的更具体类别。

例如：

鸡类 ⊂ 鸟类
鸟类 ⊂ 动物类

因此：

鸡类
↓
鸟类
↓
动物类

形成由特殊到一般的层次结构。

5.5 父类与子类的结构继承

子类不仅仅是父类的名称变化，而是可以继承父类已有的结构，并增加自身特有结构。

例如：

动物类
├── 生命状态
├── 位置
└── 移动能力

鸟类进一步增加：

鸟类
├── 羽毛
├── 翅膀
└── 飞行能力

鸡类进一步增加：

鸡类
├── 鸡冠
├── 鸣叫
└── 产蛋

于是：

动物类
↓
鸟类
↓
鸡类

形成结构逐级具体化。

因此，继承关系的主要作用是：

建立类别层级和结构传递。

5.6 兄弟类

**兄弟类（Sibling Classes）**是具有共同父类，但彼此之间不存在直接继承关系的多个类。

例如：

动物类
├── 鸟类
├── 鱼类
├── 哺乳动物类
└── 爬行动物类

其中：

鸟类
鱼类
哺乳动物类
爬行动物类

属于兄弟类。

兄弟类之间的核心关系不是：

鸟类 → 继承 → 鱼类

而是：

鸟类
↘
动物类
↗
鱼类

二者共享更高层的结构。

兄弟类理论的重要作用，是帮助机器理解：

两个类别既具有共同上位结构，又保持各自独立的特征结构。

例如：

鸟类
├── 翅膀
├── 羽毛
└── 飞行能力

鱼类
├── 鳞片
├── 鳃
└── 游动能力

它们具有共同的“动物”上位结构，但不能因此互相继承。

5.7 包含关系

**包含关系（Containment Relationship）**表示一个类的结构范围中包含另一个类。

基本形式：

整体类
↓ 包含
组成类

例如：

汽车类
↓ 包含
发动机类

表示发动机属于汽车整体结构的一部分。

进一步：

汽车类
├── 发动机类
├── 车轮类
├── 车身类
└── 制动系统类

包含关系强调的是：

A的结构中具有B。

因此：

汽车类 → 包含 → 发动机类

不是说汽车类继承发动机类，而是说明两者存在整体—部分结构。

5.8 包含关系与继承关系的区别

继承关系：

鸟类 → 动物类

表达：

鸟类属于动物类别体系。

包含关系：

汽车类 → 发动机类

表达：

发动机是汽车结构的一部分。

因此：

继承：
类 → 类
类别层次

包含：
整体类 → 部分类
结构组成

二者虽然都是类之间的关系，但机器的处理逻辑不同。

5.9 组合关系

**组合关系（Composition Relationship）**是比一般包含关系更强的整体—部分结构关系。

它表示：

一个整体类由若干具有明确结构意义的部分类共同组成。

例如：

机械臂系统类
↓
├── 底座类
├── 关节类
├── 连杆类
└── 末端执行器类

这些组成部分共同形成机械臂系统。

因此：

机械臂系统类
↓ 组合
底座类
关节类
连杆类
末端执行器类

组合关系强调：

多个部分
↓
结构组合
↓
整体

因此：

组合关系 = 整体结构由多个类共同形成。

5.10 包含与组合的区别

包含关系强调：

整体中存在某个部分。

组合关系进一步强调：

多个部分按照结构共同形成一个整体。

例如：

房屋类
↓ 包含
门类

可以表示房屋中存在门。

而：

汽车类
↓ 组合
发动机类
车轮类
车身类
制动系统类

表示这些部分共同构成汽车结构。

因此：

包含 → 部分存在
组合 → 整体形成

在机器结构建模中，这一区分能够避免把所有整体—部分关系简单地使用同一种关系表示。

5.11 关联关系

**关联关系（Association Relationship）**表示两个类之间存在稳定或可识别的结构联系，但一个类并不构成另一个类的组成部分。

例如：

人类
↓ 关联
公司类

人类与公司之间存在工作、管理、雇佣等结构关系，但公司不是人的组成部分，人也不是公司的组成部分。

又例如：

学生类
↓ 关联
学校类

学生与学校之间存在组织关系。

关联关系的基本形式是：

ClassA
↓ 关联
ClassB

它主要表达：

A与B之间存在结构上的联系。

关联关系通常比包含和组合更加宽泛。

5.12 依赖关系

**依赖关系（Dependency Relationship）**表示一个类在完成某种行为、方法或处理过程中，需要另一个类提供条件、资源或能力。

基本形式：

ClassA
↓ 依赖
ClassB

例如：

烹饪类
↓ 依赖
炉具类

表示烹饪过程中的某些方法需要炉具提供加热能力。

又例如：

加工类
↓ 依赖
工具类

加工过程需要工具才能完成。

依赖关系的特点是：

A不一定包含B，也不一定永久使用B，但A的某项能力实现需要B。

因此：

依赖 ≠ 包含
依赖 ≠ 继承

依赖描述的是能力实现上的条件关系。

5.13 控制关系

**控制关系（Control Relationship）**表示一个类能够对另一个类的行为、状态或运行过程产生控制作用。

例如：

控制器类
↓ 控制
机械臂类

控制器类负责向机械臂发送动作指令。

再例如：

炉具控制类
↓ 控制
加热设备类

可以控制：

启动
停止
温度调整
加热时间

控制关系的核心不是“拥有”，而是：

A能够改变B的运行行为。

因此：

ClassA
↓ 控制
ClassB

表示：

A
↓
控制指令
↓
B
↓
状态 / 行为变化

控制关系因此与动态行为密切相关。

5.14 使用关系

**使用关系（Usage Relationship）**表示一个类在执行某项任务时使用另一个类所提供的对象、能力、工具或资源。

例如：

人类
↓ 使用
手机类

表示人类可以使用手机。

又例如：

机械加工类
↓ 使用
机械工具类

表示加工过程使用工具完成任务。

使用关系可以表示：

使用者类
↓ 使用
资源类

与依赖关系相比，使用关系更加直接。

例如：

厨师类
↓ 使用
锅类

表达的是使用行为。

而：

烹饪类
↓ 依赖
加热能力

表达的是完成烹饪能力所需要的条件。

因此可以区分：

使用 → 谁使用什么
依赖 → 谁需要什么才能完成

5.15 控制关系与使用关系

控制与使用也不能混为一体。

例如：

人类
↓ 使用
汽车类

人可以使用汽车，但并不意味着“人类类控制汽车类”。

而：

控制系统类
↓ 控制
汽车动力系统类

表示一个系统对另一个系统的运行状态产生直接控制。

因此：

使用：
A → 使用 → B

控制：
A → 控制 → B

二者表达完全不同的结构意义。

5.16 七类主要结构关系的统一比较

类关系可以形成如下结构：

关系	核心含义	基本形式
继承	类别层级	子类 → 父类
兄弟	共享父类的平行类别	子类A ↔ 子类B
包含	整体包含部分	整体类 → 部分类
组合	多个部分形成整体	部分类 → 整体类
关联	两类存在结构联系	A → B
依赖	A完成能力需要B	A → 依赖 → B
控制	A改变B的行为或状态	A → 控制 → B
使用	A使用B提供的资源或能力	A → 使用 → B

这里的“兄弟类”严格来说不是一种与其他关系完全相同的有向关系，而是一种类层级结构状态。

例如：

父类
├── 子类A
└── 子类B

子类A和子类B因此形成兄弟结构。

5.17 类关系的方向性

类关系通常具有方向。

例如：

汽车类 → 包含 → 发动机类

与：

发动机类 → 包含 → 汽车类

并不是同一个意思。

同样：

控制器类 → 控制 → 机械臂类

不能随意写成：

机械臂类 → 控制 → 控制器类

因此机器必须保存：

source_class
relation_type
target_class

也就是：

起始类
↓
关系类型
↓
目标类

这样才能准确表达世界结构。

5.18 类关系的传递性

不同关系具有不同的传递性质。

例如继承关系通常可以形成层级传递：

鸡类
↓
鸟类
↓
动物类

因此机器可以推导：

鸡类属于鸟类结构
鸡类属于动物类结构

但是使用关系不能简单地这样传递：

人类 → 使用 → 手机类
手机类 → 使用 → 网络类

不能因此直接推出：

人类 → 使用 → 网络类

是否成立必须由具体知识确定。

控制关系同样如此。

因此：

类关系不仅需要记录“连接”，还必须记录关系本身的逻辑性质。

机器不能把所有关系都当成同一种可传递关系。

5.19 类关系与对象关系

类关系解决：

类别之间是什么关系？

对象关系解决：

具体对象之间是什么关系？

例如类层：

人类
↓ 使用
手机类

对象层：

张三
↓ 使用
手机01

类层表达的是一般结构。

对象层表达的是现实实例。

因此：

类关系
↓
可能的结构范围
↓
对象关系
↓
现实中的具体结构

例如：

锅类
↓ 包含
食材类

现实中：

锅01
↓ 包含
鸡蛋01

但是，类关系不能机械决定所有对象关系。

对象关系还必须受到：

对象属性
+
对象状态
+
时间
+
空间
+
场景

的影响。

这为下一阶段的“对象关系理论”提供了理论基础。

5.20 类关系与场景形成

类关系的最终意义不是建立一张静态关系表，而是为机器理解现实场景提供结构基础。

例如：

机械臂类
↓ 控制
夹持器类

夹持器类
↓ 使用
抓取方法类

鸡蛋类
↓ 可被处理
烹饪类

现实对象形成：

机械臂01
↓ 控制
夹持器01

夹持器01
↓ 抓取
鸡蛋01

最终形成：

机械臂01
+
夹持器01
+
鸡蛋01
+
桌面01

构成一个动态场景。

因此：

类关系
↓
结构知识
↓
对象关系
↓
场景结构
↓
认知

类关系是场景认知的上层结构基础。

5.21 类关系的动态性

基础类具有相对稳定性，但类之间的组织关系并不是绝对静态的。

例如，在不同任务中：

机械臂类
↓ 使用
抓取工具类

在另一个任务中：

机械臂类
↓ 使用
焊接工具类

类本身没有改变：

机械臂类
抓取工具类
焊接工具类

变化的是任务场景中的结构组织。

进一步：

任务
↓
认知匹配
↓
相关类被选择
↓
类关系被激活
↓
形成任务结构

因此可以提出：

基础类相对稳定，类关系具有情境激活性，动态场景则是类关系在具体对象上的现实展开。

这为后面的动态类组织理论提供基础。

5.22 类关系与认知匹配

机器面对一个新场景时，并不是简单寻找一个类，而是寻找：

对象
+
属性
+
状态
+
关系
+
行为
+
场景

然后匹配已有类结构。

例如机器面对：

机械臂01
鸡蛋01
锅01
炉具01

机器需要判断：

机械臂类
鸡蛋类
锅类
炉具类

以及它们之间可能存在：

控制关系
使用关系
包含关系
依赖关系
处理关系

于是：

类匹配
+
关系匹配
+
对象匹配
+
状态匹配
↓
场景认知

这说明：

类关系是认知匹配的重要结构依据。

机器不是只匹配“这个东西是什么”，还必须匹配：

“这个东西与其他东西是什么关系。”

5.23 类关系的工程表示

在工程系统中，可以建立统一的类关系对象：

ClassRelation
{
    id
    source_class_id
    target_class_id
    relation_type
    direction
    weight
    conditions
    status
}

其中：

source_class_id：起始类；
target_class_id：目标类；
relation_type：关系类型；
direction：关系方向；
weight：关系强度或优先级；
conditions：关系成立条件；
status：关系当前状态。

关系类型可以定义为：

INHERIT
CONTAIN
COMPOSE
ASSOCIATE
DEPEND
CONTROL
USE

兄弟类则可以通过共同父类推导：

ParentClass
├── ClassA
└── ClassB

这样无需人为保存大量重复的“兄弟关系”。

5.24 类关系数据库结构

如果映射到结构化数据库，可以建立：

classes
├── id
├── name
└── parent_id

以及：

class_relations
├── id
├── source_class_id
├── target_class_id
├── relation_type
├── direction
└── status

例如：

source_class_id = 汽车类
target_class_id = 发动机类
relation_type = COMPOSE

表示：

汽车类
↓ 组合
发动机类

而：

source_class_id = 鸟类
target_class_id = 动物类
relation_type = INHERIT

表示：

鸟类
↓ 继承
动物类

通过统一的关系结构，机器就能够计算、查询和维护类之间的结构网络。

5.25 类关系网络

当类数量增加以后，类关系会形成网络：

             动物类
          ↙          ↘
       鸟类          哺乳动物类
      ↙   ↘
    鸡类   鹰类
     ↓
   鸡蛋类

人类
 ↓ 使用
锅类
 ↓ 包含
炉具类

此时机器获得的已经不再是：

类A
类B
类C
类D

而是：

类
↓
关系
↓
结构网络

这意味着机器知识从“类别集合”发展为“结构化类别体系”。

5.26 类关系理论的核心原则

本章可以归纳出八项基本原则。

第一，层级原则。

父类与子类建立类别层级。

父类
↓
子类

第二，兄弟类原则。

共享父类的平行子类形成兄弟结构。

父类
├── A类
└── B类

第三，包含原则。

整体类可以包含部分类。

整体类 → 包含 → 部分类

第四，组合原则。

多个部分类可以共同形成整体类。

部分A
+
部分B
+
部分C
↓
整体

第五，关联原则。

两个类可以通过一般结构联系建立关联。

第六，依赖原则。

一个类的能力实现可能依赖另一个类提供的条件或能力。

第七，控制原则。

一个类可以对另一个类的行为或状态产生控制作用。

第八，使用原则。

一个类可以在任务执行过程中使用另一个类提供的资源或能力。

5.27 类关系统一模型

综合本章，可以建立：

类A
│
├── 继承 → 类B
├── 包含 → 类C
├── 组合 → 类D
├── 关联 → 类E
├── 依赖 → 类F
├── 控制 → 类G
└── 使用 → 类H

因此，一个类并不是孤立节点，而是具有多个方向和多个语义层次的结构节点。

最终形成：

类
↓
类关系
├── 层级关系
├── 结构关系
├── 功能关系
├── 依赖关系
└── 控制关系
↓
类结构网络

5.28 本章总结

本章建立了机器世界中的类关系理论。

类关系解决的问题不是“一个类是什么”，而是：

一个类与其他类之间是什么关系。

由此形成：

父类 → 子类

建立类别层级；

共同父类
├── 兄弟类A
└── 兄弟类B

建立平行类别结构；

整体类 → 包含 → 部分类

建立整体—部分关系；

多个部分类
↓
组合
↓
整体类

建立组合结构；

类A → 关联 → 类B

建立一般结构联系；

类A → 依赖 → 类B

表示能力实现上的依赖；

类A → 控制 → 类B

表示行为或状态控制；

类A → 使用 → 类B

表示资源和能力的使用。

最终形成：

世界
↓
基础类
↓
类关系
↓
类结构网络
↓
对象实例
↓
对象关系
↓
场景
↓
认知

因此，本章最核心的理论结论是：

类不是孤立存在的类别节点，而是通过继承、包含、组合、关联、依赖、控制和使用等不同关系形成具有层次、结构和功能意义的类关系网络。类关系规定了类别之间可能存在的结构联系，对象实例则把这些抽象关系进一步展开为现实世界中的具体关系。

由此，第1章至第5章已经形成了一条完整的世界结构基础链：

世界
↓
基础类
↓
对象实例
↓
类—对象结构关系
↓
类关系
↓
对象关系
↓
场景

下一阶段的关键问题将从“类与类是什么关系”进一步进入“对象与对象在现实世界中是什么关系”。也就是说，需要研究类关系如何在具体对象之间实例化，以及位置、接触、包含、拥有、操作、作用、依赖等对象关系如何共同形成动态场景。

第5章 类关系理论

第5章 类关系理论

5.1 提出背景

5.2 类关系的定义

5.3 类关系的基本分类

5.4 父类与子类

5.5 父类与子类的结构继承

5.6 兄弟类

5.7 包含关系

5.8 包含关系与继承关系的区别

5.9 组合关系

5.10 包含与组合的区别

5.11 关联关系

5.12 依赖关系

5.13 控制关系

5.14 使用关系

5.15 控制关系与使用关系

5.16 七类主要结构关系的统一比较

5.17 类关系的方向性

5.18 类关系的传递性

5.19 类关系与对象关系

5.20 类关系与场景形成

5.21 类关系的动态性

5.22 类关系与认知匹配

5.23 类关系的工程表示

5.24 类关系数据库结构

5.25 类关系网络

5.26 类关系理论的核心原则

5.27 类关系统一模型

5.28 本章总结