4. 数据模型定义与继承体系

在 Teamcenter BMIDE 中，数据模型不是一张平铺的字段表，而是一棵由 Business Object（业务对象）类型构成的继承树。理解这棵树的结构与规则，决定了后续属性扩展、关系定义、扩展点挂接能否稳定落地。本节围绕抽象对象与具体对象、继承与多态、扩展点机制，以及对象层次设计原则和常见建模模式展开。

抽象对象与具体对象

BMIDE 中的 Business Object 分为抽象（Abstract）与具体（Concrete）两类。抽象对象不能直接实例化，它存在的意义是承载一组子类型共有的属性、关系与行为契约，例如 POM_object、WorkspaceObject、BusinessObject 这类根级或中间层类型。具体对象可以被创建为真实数据实例，例如 Item、ItemRevision、Folder、Dataset。

判断一个类型该不该设为抽象，核心看两点：它是否会被直接创建为业务数据；它的属性集合是否只对子类型有意义。若某类型只是“分类容器”，就应设为抽象，避免用户误建无意义实例。BMIDE 中通过类型属性面板的 Abstract 标志控制，勾选后该类型不出现在创建菜单中。

继承与多态

继承让子类型自动获得父类型的属性、关系与扩展点。Teamcenter 采用单继承为主的对象层次，子类型可重写父类型属性的默认值、约束与显示行为。多态则体现在运行时：当业务代码或扩展点以父类型为参数时，实际传入的可以是任意子类型实例，系统按实例的真实类型分派行为。

例如定义抽象类型 CompanyDocument，其下派生 DesignSpec 与 QualityReport。若某扩展点声明接收 CompanyDocument，则两类文档实例都能进入该扩展点，扩展点内部再依据 type_name 或属性值做差异化处理。这就是继承加多态在 BMIDE 扩展开发中的典型用法。

扩展点机制

扩展点是 BMIDE 提供的“可插拔行为入口”。常见扩展点包括 postCreate、preSave、postSave、preDelete 等生命周期钩子，以及自定义操作扩展点。扩展点声明在类型上，运行时按对象真实类型触发。设计扩展点时要注意：扩展点应声明在足够抽象的父类型上，让多态发挥作用；同时避免在根类型上挂载过重逻辑，否则所有子类型都会承担不必要的开销。

对象层次设计原则

设计继承树时，建议遵循以下原则：

• 单一职责：一个类型只表达一类业务语义，不要把“文档”和“审批流”混在同一类型里。
• 抽象层稳定：越靠近根的抽象类型越应稳定，属性尽量少而通用；易变属性下沉到具体子类型。
• 避免过深继承：层次建议控制在 4～5 层以内，过深会导致属性来源难以追踪、扩展点触发顺序复杂。
• 优先组合：能用关系（Relation）或引用表达的结构，不要强行用继承表达。
• 命名一致：抽象类型用通用名词，具体类型用业务名词，便于在 BMIDE 类型树中快速定位。

常见建模模式

实践中常见三种模式。第一种是模板方法模式：在抽象父类型上定义扩展点骨架，子类型实现具体逻辑，适合文档审批、编码生成等场景。第二种是策略模式：通过关系挂接不同策略对象，运行时按条件选择，适合多套校验规则并存。第三种是类型—版本分离模式：Item 与 ItemRevision 分离，主对象承载标识与分类，版本对象承载具体属性与状态，这是 Teamcenter 最核心的建模惯例。

综合来看，抽象对象定义契约，具体对象承载数据，继承复用结构，多态支撑扩展，扩展点提供行为入口。把这五者关系理清，再结合稳定的抽象层与合理的层次深度，就能设计出可维护、可扩展的 Teamcenter 数据模型。