智慧建筑集成技术中的多重继承及相关术语

对象的合同列表可以指定要实现的多个合同URI，这实际上很常见，甚至在许多情况下都需要，与多重合同的实施相关的术语如表5-10 所示。

表5-10　多重合同相关术语

1. Flattening

合同对象本身通常实现合同，就像在面向对象语言中链接继承层次结构一样。然而，由于通过网络访问OBIX 文档的性质，通常希望最小化“学习”复杂合同层次结构可能需要的往返网络请求。考虑这个例子：

在此示例中，如果OBIX 客户端第一次读取对象D，则需要另外三个请求才能完全了解实现了哪些合同（一个用于C，B 和A）。此外，如果客户端只是在寻找实现B 的对象，那么仅通过查看D 就很难确定。

由于存在这些问题，在指定is，of，in 或out 属性时，服务器必须将其Contract继承层次结构展平为列表。在上面的示例中，正确的表示形式为：

这允许客户端快速扫描D 的合同列表，以查看D 在没有进一步请求的情况下实现C，B 和A。由于复杂的服务器通常具有对象类型的复杂合同层次结构，扁平合同层次结构的要求可能会导致详细的合同列表。通常，这些合同中的许多来自同一名称空间，例如：

为了节省空间，服务器可以选择合并来自同一名称空间的合同，并使用命名空间后冒号，然后是括号括起的合同名称列表来显示：

(www.xing528.com)

客户端必须能够使用这种形式的合同清单并将其扩展到标准形式。

2. Mixins

展平不是合同列表可能包含多个合同URI 的唯一原因，OBIX 还支持使用mixin 方法的更传统的多重继承概念，如下例所示：

在这个例子中，ClockRadio 实现了Clock 和Radio。通过对时钟和无线电进行扁平化，ClockRadio 也实现了Device。在OBIX 中，这被称为mixin，Clock，Radio 和Device 被混合到（合并到）ClockRadio 中。因此，ClockRadio 继承了四个子节点：serialNo，snooze，volume 和station。Mixins 是一种类似于Java/C＃接口的多重继承形式（记住OBIX 是关于类型继承，而不是实现继承）。

注意，Clock 和Radio 都实现了Device。这种继承模式，其中两个类型都从一个基类继承，并且它们本身都由一个类型继承，从表示层次结构时所采用的形状称为“菱形”模式。从Device，ClockRadio 继承了一个名为serialNo 的子节点。此外，注意Clock 和Radio 都声明了一个名为volume 的子节点，这种命名冲突可能会对ClockRoio 中serialNo 和volume 的含义造成混淆。OBIX 通过使用以下规则展平Contract 的子项来解决此问题：

（1）按照列出的顺序处理合同定义。

（2）如果发现了新的孩子，它会被混合到对象的定义中。

（3）如果发现已经通过先前的合同定义处理的子项，则先前的定义优先。如果重复的子项与先前的定义不兼容，则会出错。

在上面的示例中，这意味着Radio.volume 是用于ClockRadio.volume 的定义，因为Radio 具有比Clock 更高的优先级（它在合同列表中是第一个）。因此，ClockRadio.volume 的默认值为“5”。但是，如果将Clock.volume 声明为str，那么它将无效，因为它不会与Radio 的定义作为int 兼容，在这种情况下，ClockRadio 无法同时实现Clock 和Radio，服务器供应商有责任不在合同中创建不兼容的名称冲突。

列表中的第一个合同具有特殊意义，因为其定义胜过所有其他合同。在OBIX 中，此合同称为主合同。出于这个原因，主合同应该实现合同列表中指定的所有其他合同（这实际上在许多编程语言中很自然地发生）。如果需要，这使客户端更容易将Object 绑定到强类型类中。合同不得实现自己，也不得具有循环继承依赖性。