UML类图关系详解

2026-04-26

字数统计: 7.5k字 | 阅读时长≈ 29分

一文看懂UML的各种关系

导读：本文将系统讲解UML类图中的6种核心关系，并结合C++代码实现，帮助你建立从设计图到代码的完整认知。

一. UML有Java和C++之分吗

💡 这是一个非常敏锐的观察！

简单来说：UML 本身是跨语言、独立于具体编程语言的，所以并没有官方的”C++ 版本”或”Java 版本”的 UML 类图。但是，由于不同编程语言的特性不同，UML 图在映射（落地）到具体代码时，会产生不同的对应关系。你注意到的 <<interface>> 就是一个最典型的例子。

📌 核心观点：UML是”通用设计图纸”，而C++和Java是不同的”建筑材料”。

以下是关于 <<interface>> 以及 UML 在 C++ 和 Java 中差异的详细解释：

1. `<<interface>>` 是 UML 的标准，不是 Java 的专利

在 UML 中，包裹在双尖括号里的词被称为构造型（Stereotype）。<<interface>> 是 UML 官方定义的一种标准构造型，用来表示这个”类”只是一个接口，只定义行为约定，不包含具体实现。

2. 在 Java 中的映射

Java 语言本身就在语法层面原生支持 interface 关键字。因此，当你在 UML 中画了一个带有 <<interface>> 的类图时，在 Java 中有着百分之百的直接映射：

// UML 中的 <<interface>> 直接变成了 Java 的 interface
public interface MyInterface {
    void doSomething();
}

3. 在 C++ 中的映射

C++ 语言在语法标准中并没有 interface 这个关键字。但是，C++ 完全具备面向接口编程的能力。

在 C++ 开发中，如果我们在 UML 图里画了一个带有 <<interface>> 的类，它在 C++ 代码中会被映射为包含纯虚函数的抽象类（Abstract Class）。通常，这个类里不包含任何成员变量，且所有的成员函数都是纯虚函数。

// UML 中的 <<interface>> 在 C++ 中通常被实现为纯虚基类
class MyInterface {
public:
    virtual ~MyInterface() = default; // 虚析构函数是必需的
    virtual void doSomething() = 0;   // 纯虚函数
};

✅ 结论：在 C++ 的 UML 图中，完全可以（并且强烈建议）使用 <<interface>> 字样。 虽然 C++ 代码里写不出 interface 这个词，但在前期架构设计和画 UML 图时，标出 <<interface>> 可以极其清晰地向其他开发者传达你的设计意图：”这是一个纯粹的接口，请去继承并实现它，不要试图实例化它。”

其他常见的”语言映射”差异

除了接口之外，UML 在面对 C++ 和 Java 时还有几个常见的微小习惯差异：

特性	C++	Java
多重继承	✅ 完全支持	❌ 不支持（仅支持接口多实现）
属性访问	灵活，可直接暴露或封装	习惯使用 Getter/Setter
接口实现	纯虚基类	`interface` 关键字

💡 小贴士：如果在针对 Java 项目的 UML 中画了多重类继承，往往说明设计出现了问题，需要重构。

总结来说：UML 是一种”通用设计图纸” 📐。画图时使用的是全行业通用的标准符号（包括 <<interface>>），而具体盖成”C++ 大楼”还是”Java 大楼”，则取决于开发人员如何用各自语言的砖块去实现这份图纸。

🔜 接下来，让我们从最简单、最基础的关联关系开始，逐步深入理解UML的6种核心关系。

二. 关联关系

在面向对象设计中，关联关系（Association） 是最基础、最常见的一种对象间关系。它表示一个类的对象”知道”另一个类的对象，并且可以在逻辑上或物理上访问它。简单来说，就是**“某个对象属于另一个对象的运行环境”，或者说它们之间有“使用”或”拥有”**的关系。

1. UML 中的表示方法

在 UML 类图中，关联关系用一条实线来表示。根据双方是否互相知道对方的存在，关联又分为两种：

单向关联（Unidirectional Association）： 一条带开放箭头的实线。箭头指向被知道/被使用的类。比如 A -> B，表示 A 知道 B，但 B 不知道 A。
双向关联（Bidirectional Association）： 一条没有箭头的普通实线。表示 A 知道 B，同时 B 也知道 A。

此外，实线的两端通常还会标注多重性（Multiplicity），比如 1（刚好一个）、0..1（零或一个）、*（多个），用来精确描述数量关系。

2. 在 C++ 中的代码映射

在 C++ 中，由于关联关系强调的是**“两个独立的生命周期”（即 A 被销毁了，B 依然可以独立存在），所以我们通常不会在类中直接存放另一个类的实例（值传递），而是使用指针（Pointer）或引用（Reference）**。

在现代 C++ 中，为了内存安全，通常会使用裸指针（表示不拥有生命周期）或者智能指针（如 std::shared_ptr 或 std::weak_ptr）。

3. 一个生动且详细的例子

为了让你更好地理解，我们来构思一个经典的香港老电影场景：男主角（比如刘德华饰演的角色）和他的重型摩托车。

这就是一个极其典型的单向关联关系。

概念理解：

**主角（Person）和摩托车（Motorcycle）**是两个完全独立的客观事物，它们有各自的生命周期。
主角随时可以骑上这辆摩托车去兜风（主角”知道”并”使用”摩托车）。
但如果主角去吃饭了，摩托车依然停在楼下（主角离开，摩托车不灭亡）。
同理，如果这辆摩托车报废了，主角依然活着，他还可以去换一辆新车（摩托车灭亡，主角不灭亡）。
通常情况下，是人去操控摩托车，而摩托车不需要知道”是谁在骑我”，所以这往往是一个单向关联。

UML 类图：

classDiagram
    class Person {
        - name: String
        - myBike: Motorcycle*
        + Person(n: String)
        + getOnBike(bike: Motorcycle*)
        + getOffBike()
        + ride()
    }
    class Motorcycle {
        - model: String
        + Motorcycle(m: String)
        + roar()
    }
    Person --> Motorcycle : 单向关联

C++ 代码实现：

#include <iostream>
#include <string>

// 摩托车类 (独立的类)
class Motorcycle {
private:
    std::string model;
public:
    Motorcycle(std::string m) : model(m) {}
    
    void roar() {
        std::cout << "这辆 " << model << " 发出了震耳欲聋的引擎轰鸣声！" << std::endl;
    }
};

// 人类 (独立的类)
class Person {
private:
    std::string name;
    // 【关键】：这里就是关联关系在 C++ 中的体现！
    // 使用指针，说明 Person "知道" 某辆摩托车的存在，但不强行绑定它的生死，就只申明，不分配内存。
    Motorcycle* myBike; 

public:
    // 构造时，人可能没有车 (nullptr)
    Person(std::string n) : name(n), myBike(nullptr) {}

    // 建立关联的方法 (男主角跨上摩托车)
    void getOnBike(Motorcycle* bike) {
        myBike = bike;
        std::cout << name << " 跨上了摩托车。" << std::endl;
    }

    // 解除关联的方法 (男主角下车)
    void getOffBike() {
        myBike = nullptr;
        std::cout << name << " 停下并离开了摩托车。" << std::endl;
    }

    // 使用关联对象的功能
    void ride() {
        if (myBike != nullptr) {
            std::cout << name << " 拧下油门..." << std::endl;
            myBike->roar(); // 调用被关联对象的方法
        } else {
            std::cout << name << " 只能靠双腿走路了。" << std::endl;
        }
    }
};

int main() {
    // 1. 创建两个独立的对象
    Motorcycle suzukiRG500("Suzuki RG500");
    Person andy("华弟");

    // 2. 此时它们还没有关联
    andy.ride(); // 输出: 华弟 只能靠双腿走路了。

    std::cout << "--- 建立关联 ---" << std::endl;
    
    // 3. 建立关联关系 (把指针传进去)
    andy.getOnBike(&suzukiRG500); 
    andy.ride(); // 输出: 华弟 拧下油门... 这辆 Suzuki RG500 发出了震耳欲聋的引擎轰鸣声！

    std::cout << "--- 解除关联 ---" << std::endl;

    // 4. 解除关联关系
    andy.getOffBike();
    
    // 5. 证明生命周期独立：摩托车依然存在，男主角也依然存在
    // 苏木吉摩托车对象依然在 main 函数的作用域里好好的。

    return 0;
}

📝 本节小结

维度	内容
UML表示	实线 + 开放箭头 (`───>`)
C++实现	指针或引用成员变量
核心本质	平等的”知道”关系，生命周期独立
记忆口诀	📞 “我有你的联系方式，但不对你的生死负责”

💭 思考一下：如果主角”拥有”摩托车，而不是仅仅”知道”摩托车，关系会发生什么变化？

🔜 接下来，让我们看看关联关系的”升级版”——聚合关系，它表达了”整体与部分”的概念。

在理解了”关联关系”之后，再来看”聚合关系”就会非常清晰。

聚合关系（Aggregation） 是关联关系的一种特例。如果说普通的关联关系是平等的”知道”与”被知道”（比如车手与摩托车），那么聚合关系表达的就是一种**“整体与部分 (Whole-Part)”** 或者 “拥有 (Has-a)” 的关系。

但它最核心的灵魂在于：**”弱拥有”（Weak Ownership）**。也就是说，部分可以脱离整体而独立存在。整体的生命周期结束了，部分并不会随之消亡。

1. UML 中的表示方法

在 UML 类图中，聚合关系用一条带空心菱形的实线来表示。

空心菱形画在**“整体”**的那一端。
实线连接**“部分”**。

2. 在 C++ 中的代码映射与逻辑本质

在 C++ 代码层面，聚合关系和普通的关联关系长得极其相似——通常都是通过指针，或者指针的集合（比如 std::vector<Part*>）来实现的。

我们绝对不会在整体类里面直接写一个对象的实例变量（比如 std::vector<Part> 或 Part part1;），也不会在整体的析构函数（~Whole()）里去 delete 这些部分。原因很简单：整体不负责给部分发工资（分配内存），也不负责给部分发饭盒（释放内存）。

3. 一个生动且详细的场景例子

既然你对 C++ 和软件架构非常熟悉，我们就用一个极具代入感的软件公司团队开发的场景来解释聚合关系。

概念理解：

假设一家公司成立了一个名为”小米科技拓扑优化办公室”的项目组（整体）。
这个项目组招募了几位优秀的 C++ 工程师（部分） 来攻克具体的算法和底层框架。
项目组”拥有（Has-a）”这些工程师，它们之间是整体与部分的关系。
弱拥有体现： 如果某天底层的小米工业算法框架开发完毕顺利交付，这个特定的拓扑优化项目组被撤销或解散了（整体消亡）。但是，这些 C++ 工程师并不会随之”人间蒸发”，他们依然是公司的员工，会被调配去写其他的代码（部分依然存活）。

UML 类图：

classDiagram
    class OptimizationTeam {
        - teamName: String
        - members: vector
        + OptimizationTeam(name: String)
        + addEngineer(eng: Engineer*)
        + startDailyMeeting()
    }
    class Engineer {
        + name: String
        + Engineer(n: String)
        + code()
    }
    OptimizationTeam o-- Engineer : 聚合关系

C++ 代码实现：

#include <iostream>
#include <string>
#include <vector>

// C++ 工程师类 (部分)
class Engineer {
public:
    std::string name;
    
    Engineer(std::string n) : name(n) {
        std::cout << "工程师 [" << name << "] 入职了。" << std::endl;
    }
    
    void code() {
        std::cout << name << " 正在专注地编写底层的 小米工业架构代码..." << std::endl;
    }
    
    ~Engineer() {
        std::cout << "工程师 [" << name << "] 离职了。" << std::endl;
    }
};

// 拓扑优化项目组类 (整体)
class OptimizationTeam {
private:
    std::string teamName;
    // 【关键】：这里是聚合关系的核心体现
    // 使用指针的集合，表明团队 "拥有" 这些工程师，但不掌控他们的生死
    std::vector<Engineer*> members; 

public:
    OptimizationTeam(std::string name) : teamName(name) {
        std::cout << ">>> 成立了项目组: " << teamName << " <<<" << std::endl;
    }

    // 将部分聚合到整体中
    void addEngineer(Engineer* eng) {
        members.push_back(eng);
        std::cout << eng->name << " 被拉进了 " << teamName << " 的微信群。" << std::endl;
    }

    void startDailyMeeting() {
        std::cout << "--- " << teamName << " 开启每日站会 ---" << std::endl;
        for(auto* eng : members) {
            std::cout << eng->name << " 汇报了昨天的代码进度。" << std::endl;
        }
    }

    ~OptimizationTeam() {
        std::cout << ">>> 项目圆满结束，" << teamName << " 正式解散 (对象被销毁) <<<" << std::endl;
        // 【注意】：在析构函数中，绝不去 delete members 里的指针！
        // 因为团队没有权力销毁工程师对象。
    }
};

int main() {
    // 1. 先有工程师个体（生命周期独立）
    Engineer dev1("小张");
    Engineer dev2("老李");
    std::cout << std::endl;

    // 2. 利用一个局部作用域 { } 来模拟项目组的生命周期
    {
        // 创建整体
        OptimizationTeam topoOffice("小米科技拓扑优化办公室");
        
        // 建立聚合关系 (把现有的指针放进去)
        topoOffice.addEngineer(&dev1);
        topoOffice.addEngineer(&dev2);
        
        // 整体带着部分一起工作
        topoOffice.startDailyMeeting();
        
    } // <-- 离开这个大括号时，topoOffice 会调用析构函数被销毁（团队解散）

    std::cout << "\n--- 验证生命周期 ---" << std::endl;
    // 3. 团队已经不在了，但是工程师依然可以调用自己的方法，证明他们独立存活
    dev1.code();
    dev2.code();
    
    return 0; // main 函数结束时，dev1 和 dev2 才会被正常销毁
}

📝 本节小结：关联 vs. 聚合

对比维度	关联 (Association)	聚合 (Aggregation)
UML符号	实线 + 箭头	实线 + 空心菱形 (`◇──`)
关系本质	平等认识	整体-部分，弱拥有
生命周期	完全独立	部分可脱离整体存活
C++实现	指针/引用	指针集合
析构责任	无	❌ 不delete部分对象
典型场景	车手与摩托车	项目组与工程师

⚠️ 关键提示：当你画出一个空心菱形时，你其实是在向其他程序员传递一个强烈的内存管理暗示：”各位，这里有个集合包含了一堆对象，但千万记得，释放这个集合的时候，别动那些对象本身！”

🔜 接下来，让我们继续强化”整体-部分”关系，看看当部分不能脱离整体存在时，会发生什么——这就是组合关系。

如果说”聚合”是团队里铁打的营盘流水的兵，那么组合（Composition，也称合成） 就是真正的**“同生共死”**。

组合关系是聚合关系的一种强化版。它依然表达的是**“整体与部分 (Whole-Part)”** 的关系，但它的灵魂在于：**”强拥有”（Strong Ownership）**。

在组合关系中，部分不能脱离整体而独立存在。整体负责部分的创建，也负责部分的销毁；整体如果不存在了，部分也就彻底灰飞烟灭了（生命周期严格一致）。

1. UML 中的表示方法

在 UML 类图中，组合关系用一条带实心菱形的实线来表示。

实心菱形（涂黑的菱形） 画在**“整体”**的那一端。
毫无疑问，实线连接的是**“部分”**。

2. 在 C++ 中的代码映射与逻辑本质

在 C++ 中，组合关系的表现形式极其明确，它直接关乎到内存管理。通常有以下三种标准写法：

直接作为成员变量（值语义，最推荐）： 直接把”部分”作为”整体”类的成员。这样当整体对象被压入栈或在堆上分配时，部分的内存就一起分配了；整体销毁，部分自然销毁。
使用独占智能指针（现代 C++ 推荐）： 使用 std::unique_ptr<Part>。这在语义上完美契合了”强拥有”——我是唯一的拥有者，我死了，它也会自动被释放。
在构造函数中 new，在析构函数中 delete（老式 C++）： 整体通过裸指针管理部分，并在析构函数中手动负责收尸。

3. 一个生动且详细的场景例子

为了准确体现这种严苛的生命周期，我们构思一个工业软件底层算法的场景：拓扑优化器（Topology Optimizer）与它内部专用的有限元求解器（FEA Solver）。

概念理解：

在进行拓扑优化时，必须通过有限元分析来计算结构的应力、位移等物理场。
我们可以把**拓扑优化器（整体）**看作是一台精密的机器。
机器内部内置了一个不可或缺的引擎——有限元求解器（部分）。
这个求解器是专门为这次优化任务定制和创建的。如果优化任务结束，或者优化器对象被销毁了，这个专用的求解器也就失去了存在的意义，必须跟着一起被销毁，释放庞大的矩阵内存。

UML 类图：

classDiagram
    class TopologyOptimizer {
        - taskName: String
        - internalSolver: unique_ptr
        + TopologyOptimizer(name: String)
        + runOptimizationIteration()
    }
    class FEASolver {
        + FEASolver()
        + solve()
    }
    TopologyOptimizer *-- FEASolver : 组合关系

C++ 代码实现（使用现代 C++ 的 `std::unique_ptr`）：

#include <iostream>
#include <string>
#include <memory>

// 有限元求解器 (部分 - 不能独立于优化器存在)
class FEASolver {
public:
    FEASolver() {
        std::cout << "  [系统底层] 分配矩阵内存，有限元求解器(FEASolver) 初始化完毕。" << std::endl;
    }
    
    void solve() {
        std::cout << "  [系统底层] 正在求解大型稀疏矩阵，计算位移场..." << std::endl;
    }
    
    ~FEASolver() {
        std::cout << "  [系统底层] 释放矩阵内存，有限元求解器(FEASolver) 彻底销毁。" << std::endl;
    }
};

// 拓扑优化器 (整体)
class TopologyOptimizer {
private:
    std::string taskName;
    
    // 【关键】：这里是组合关系的核心体现！
    // 使用 std::unique_ptr 表达"强拥有"和"同生共死"。
    // 求解器属于且仅属于这个优化器。
    std::unique_ptr<FEASolver> internalSolver; 

public:
    // 整体在诞生的时候，负责把部分也一起创造出来
    TopologyOptimizer(std::string name) : taskName(name) {
        std::cout << ">>> 开启拓扑优化任务: " << taskName << " <<<" << std::endl;
        
        // 整体负责分配部分的内存
        internalSolver = std::make_unique<FEASolver>(); 
    }

    void runOptimizationIteration() {
        std::cout << "--- 正在执行 [" << taskName << "] 的拓扑更新迭代 ---" << std::endl;
        // 整体调用部分的功能
        internalSolver->solve();
        std::cout << "--- 迭代完成，更新材料密度 ---" << std::endl;
    }

    // 现代 C++ 中，unique_ptr 会在 TopologyOptimizer 析构时自动销毁 FEASolver
    // 如果是裸指针，这里必须写： delete internalSolver;
    ~TopologyOptimizer() {
        std::cout << ">>> 拓扑优化任务 [" << taskName << "] 结束，优化器即将销毁。 <<<" << std::endl;
    }
};

int main() {
    std::cout << "=== 软件开始运行 ===" << std::endl;
    
    // 利用局部作用域模拟一个完整的生命周期
    {
        // 1. 创建整体。在这个瞬间，整体内部会触发部分的创建 (Composition)
        TopologyOptimizer optimizer("悬臂梁轻量化设计");
        
        // 2. 执行业务逻辑
        optimizer.runOptimizationIteration();
        
    } // <-- 离开作用域，optimizer 被销毁。
      // 注意控制台输出：伴随着 optimizer 的销毁，FEASolver 也会被严格销毁！

    std::cout << "=== 软件结束运行 ===" << std::endl;
    
    // 此时，不仅优化器没了，求解器也绝对找不到了。它们生死与共。
    return 0;
}

总结三者的进阶对比

为了防止混淆，可以这样记忆这三种关系（从弱到强）：

关联（实线 + 箭头）： **”我知道你”**。我有你的联系方式（指针），但我管不着你的死活。（男主角与他的摩托车）
聚合（空心菱形）： **”我包含你”**。你是我们团队的一员（指针集合），我带你一起干活，但我解散了你还能去别处。（项目组与 C++ 工程师）
组合（实心菱形）： **”我就是由你构成的”**。你是我身体的一部分（值变量或独占智能指针），我生你生，我死你死。（拓扑优化器与它内部的求解器）

在 UML 设计图纸中，当你画下一个实心菱形时，你实际上是在对后续写 C++ 代码的人下达一道极其严肃的内存管理指令：**”请确保在析构这个类的时候，把里面的这个东西彻底清理干净，绝对不能发生内存泄漏！”**

📝 本节小结：三种”拥有”关系的递进

关联 (Association)  →  聚合 (Aggregation)  →  组合 (Composition)
     平等认识      →      弱拥有        →       强拥有
   "我知道你"      →    "我包含你"      →     "我由你构成"
    完全独立       →   可独立存活       →      同生共死

关系	UML符号	生命周期	记忆口诀
关联	`───>`	完全独立	📞 “我知道你的电话”
聚合	`◇──`	部分可独立	👥 “团队解散，成员还在”
组合	`◆──`	同生共死	❤️ “你中有我，我中有你”

🔜 接下来，让我们跳出”拥有”关系的范畴，看看一种更弱、更临时的关系——依赖关系。

如果说”关联”、”聚合”和”组合”都是在讨论对象的**“常驻关系”（谁拥有谁，谁和谁绑定），那么依赖关系（Dependency）** 讨论的就是一种**“临时借用”或“偶然相遇”**的关系。

依赖关系是所有 UML 关系中最弱的一种，但同时也是最常见的一种。它表达的是一种 “使用 (Uses-a)” 的关系：一个类需要用到另一个类的某些功能或数据，但它们之间并没有长期的绑定关系。

最核心的特征是：如果被依赖的类发生了修改，依赖它的类也会受到影响（比如编译报错、逻辑改变等）。

1. UML 中的表示方法

在 UML 类图中，依赖关系用一条带开放箭头的虚线来表示。

虚线代表这种关系是脆弱的、临时的。
箭头指向**“被依赖”**的类（即提供服务的那个类）。比如 A - - - > B，表示 A 依赖 B。

2. 在 C++ 中的代码映射与逻辑本质

在 C++ 代码中，依赖关系绝对不会体现为类的成员变量。如果你把一个对象存成了成员变量，那就升级成关联/聚合/组合了。

依赖关系通常出现在类的**成员函数（方法）**内部，最常见的有以下四种 C++ 代码表现形式：

作为函数的参数： void process(Tool* t); 或者 void process(const Tool& t);
在函数内部实例化的局部变量： 函数里 Tool t; t.doSomething();
作为函数的返回值： Tool createTool();
调用了另一个类的静态方法： Tool::globalAction();

3. 一个生动且详细的场景例子

既然你在做拓扑优化的项目，我们就以 小米工业软件在处理网格数据时 的场景为例，来看看什么是典型的”依赖关系”。

概念理解：

在你的小米工业项目中，有一个核心类叫 OptimizationModel（优化模型），它负责管理整个拓扑优化的物理场和材料密度。
为了建立这个模型，你需要读取外部的网格文件（比如 Gmsh 生成的 .msh 文件）。
为此，你写了一个专门的工具类叫 MeshParser（网格解析器）。
依赖的体现： OptimizationModel 只需要在”导入数据”的那一瞬间使用 MeshParser。解析器把节点和单元数据提取出来交给模型后，解析器的任务就结束了，可以被销毁了。模型不需要在自己的生命周期里一直保存一个 MeshParser 成员变量。这就好比**“你请了个水管工来修水管，修完付钱他就走了，你不需要把他养在家里”**。

UML 类图：

classDiagram
    class FITK_Model {
        - modelName: String
        - nodes: vector
        + FITK_Model(name: String)
        + importMeshLocally(filePath: String)
        + updateMeshFromParser(parser: MeshParser&, filePath: String)
    }
    class MeshParser {
        + MeshParser()
        + parseGmshFile(filePath: String): vector
    }
    FITK_Model ..> MeshParser : 依赖关系

C++ 代码实现：

#include <iostream>
#include <string>
#include <vector>

// 被依赖的类：网格解析器 (相当于工具人)
class MeshParser {
public:
    MeshParser() {
        std::cout << "  [工具] MeshParser 被创建了。" << std::endl;
    }

    // 解析外部网格文件，返回包含节点数据的集合
    std::vector<int> parseGmshFile(const std::string& filePath) {
        std::cout << "  [工具] 正在读取并解析 Gmsh 文件: " << filePath << std::endl;
        // 模拟解析过程...
        return {101, 102, 103, 104}; // 返回解析出的节点 ID
    }

    ~MeshParser() {
        std::cout << "  [工具] MeshParser 用完被销毁了。" << std::endl;
    }
};

// 依赖类：小米工业优化模型
class FITK_Model {
private:
    std::string modelName;
    std::vector<int> nodes; // 模型拥有的是数据本身，而不是解析器对象
    // 【注意】：这里绝对没有 MeshParser 的成员变量！

public:
    FITK_Model(std::string name) : modelName(name) {
        std::cout << ">>> 初始化 小米工业模型: " << modelName << " <<<" << std::endl;
    }

    // 【关键】：这里是依赖关系的核心体现！
    // 依赖形式 1：作为函数的局部变量
    void importMeshLocally(const std::string& filePath) {
        std::cout << "\n--- 开始局部导入网格 ---" << std::endl;
        
        // 实例化局部对象，产生依赖
        MeshParser parser; 
        nodes = parser.parseGmshFile(filePath); // 使用它的功能
        
        std::cout << "--- 网格导入完成，获取了 " << nodes.size() << " 个节点 ---" << std::endl;
        // 函数结束时，parser 这个局部变量就自动灰飞烟灭了。
    }

    // 【关键】：另一种常见的依赖形式
    // 依赖形式 2：作为函数参数传入 (按引用传递，避免拷贝)
    void updateMeshFromParser(MeshParser& externalParser, const std::string& filePath) {
        std::cout << "\n--- 开始通过外部传入的解析器更新网格 ---" << std::endl;
        
        // 我只用你这一次，不保存你的指针或引用到我的成员变量里
        nodes = externalParser.parseGmshFile(filePath); 
        
        std::cout << "--- 网格更新完成 ---" << std::endl;
    }
};

int main() {
    // 1. 创建模型对象
    FITK_Model myModel("悬臂梁_V1");

    // 2. 演示依赖形式 1 (局部变量)
    // 在这个函数调用的瞬间，FITK_Model 临时依赖了 MeshParser
    myModel.importMeshLocally("beam_mesh.msh");

    // 3. 演示依赖形式 2 (函数参数)
    // 外部有一个解析器，临时传进去用一下
    MeshParser globalParser;
    myModel.updateMeshFromParser(globalParser, "beam_refined.msh");

    return 0;
}

📝 本节小结：四种”横向”关系图谱

到这里，C++ 中最核心的四种横向协作关系你就全部集齐了：

耦合强度递进（从弱到强）：

依赖 ────────→ 关联 ────────→ 聚合 ────────→ 组合
(临时借用)     (平等认识)     (松散组装)     (同生共死)
  🔧 电钻       📞 朋友        👥 团队        ❤️ 器官

关系	强度	UML符号	记忆口诀	典型场景
依赖	⭐ 最弱	`..>`	🔧 “用完就扔”	借用电钻
关联	⭐⭐ 弱	`-->`	📞 “认识但不负责”	电工朋友
聚合	⭐⭐⭐ 中	`◇--`	👥 “团队与成员”	项目组
组合	⭐⭐⭐⭐ 强	`◆--`	❤️ “同生共死”	器官与身体

💡 关键洞察：这四种关系都在讨论对象之间的**“横向协作”**——大家都是平等的个体，只是协作的紧密程度不同。

🔜 接下来，让我们把视角从”横向协作”转向**“纵向传承”**——看看泛化关系（继承）是如何工作的。

六. 泛化关系

太棒了，我们这就来把这块拼图补齐！如果说前面讲的依赖、关联、聚合、组合都是对象之间的**“横向协作”（大家都是平等的个体，互相帮忙），那么泛化（Generalization）** 讲的就是对象之间的**“纵向传承”**。

在 C++ 中，泛化关系有一个大家再熟悉不过的名字：继承（Inheritance）。它表达的是一种 “是一个 (Is-a)” 的关系。

1. UML 中的表示方法

在 UML 类图中，泛化关系用一条带空心三角箭头的实线来表示。

空心三角箭头永远指向父类（基类 / Base Class）。
实线的另一头连接子类（派生类 / Derived Class）。
视觉记忆法：三角形就像一把伞，父类在上面撑伞（提供共用的属性和方法），子类在下面乘凉（继承并扩展）。

2. 在 C++ 中的代码映射与逻辑本质

在 C++ 中，泛化通常体现为 public 继承（公有继承是最符合 UML 泛化语义的，因为它严格保证了”子类是一个父类”的原则）。

泛化关系的核心目的有两个：

代码复用： 儿子直接继承老子的财产（成员变量）和技能（成员函数），不用从头再写一遍。
多态（Polymorphism）： 这是 C++ 泛化最强大的地方。通过虚函数（virtual），允许以统一的方式去调用不同子类的特定实现。

3. 一个生动且详细的场景例子

既然我们在探讨底层架构，我们就以 小米工业软件中的有限元网格处理模块 为例。在进行拓扑优化计算时，网格是由无数个”单元（Element）”组成的，而单元有着不同的形状。

概念理解：

我们需要一个父类：有限元单元（Finite Element）。所有的单元不管长什么样，都有一些共性：都有一个全局编号（ID），都由若干个节点组成，都需要计算各自的”刚度矩阵”。
但是具体的计算公式，不同形状的单元完全不一样。所以我们需要子类。
比如：六面体单元（Hexahedron Element，比如 Hex8） 和 四面体单元（Tetrahedron Element，比如 Tet4）。
泛化的体现： 六面体单元 “是一个” 有限元单元；四面体单元也 “是一个” 有限元单元。它们继承了通用的 ID 属性，但各自重写了刚度矩阵的计算方法。

UML 类图：

classDiagram
    class FiniteElement {
        # elementId: int
        # elementType: String
        + FiniteElement(id: int, type: String)
        + getId(): int
        + computeStiffnessMatrix() virtual
    }
    class HexahedronElement {
        + HexahedronElement(id: int)
        + computeStiffnessMatrix() override
    }
    class TetrahedronElement {
        + TetrahedronElement(id: int)
        + computeStiffnessMatrix() override
    }
    FiniteElement <|-- HexahedronElement : 泛化关系
    FiniteElement <|-- TetrahedronElement : 泛化关系

C++ 代码实现：

#include <iostream>
#include <string>
#include <vector>

// ==========================================
// 父类：通用有限元单元 (Generalization 的目标)
// ==========================================
class FiniteElement {
protected:
    // 保护成员：子类可以直接访问（继承老子的财产）
    int elementId;
    std::string elementType;

public:
    FiniteElement(int id, std::string type) : elementId(id), elementType(type) {
        // 父类负责初始化通用的属性
    }

    // 虚析构函数：在 C++ 中，有泛化关系时基类必须有虚析构，防止内存泄漏！
    virtual ~FiniteElement() = default;

    // 通用方法：所有子类都不用重写，直接拿来用
    int getId() const {
        return elementId;
    }

    // 【关键】：虚函数 (Virtual Function)
    // 允许子类根据自己的几何特性去"重写"具体的计算逻辑
    virtual void computeStiffnessMatrix() {
        std::cout << "  [系统警告] 调用了基类的刚度计算方法，这通常是不对的！" << std::endl;
    }
};

// ==========================================
// 子类 A：六面体单元 (继承自 FiniteElement)
// ==========================================
class HexahedronElement : public FiniteElement {
public:
    // 调用父类构造函数，完成基础属性的初始化
    HexahedronElement(int id) : FiniteElement(id, "六面体 (Hex8)") {}

    // 【关键】：重写 (Override) 父类的虚函数
    void computeStiffnessMatrix() override {
        std::cout << "  单元 [" << elementId << "] (" << elementType 
                  << ") -> 正在使用 8 节点高斯积分计算局部刚度矩阵..." << std::endl;
        // 里面是复杂的雅可比矩阵、形函数求导等底层 C++ 数学运算...
    }
};

// ==========================================
// 子类 B：四面体单元 (继承自 FiniteElement)
// ==========================================
class TetrahedronElement : public FiniteElement {
public:
    TetrahedronElement(int id) : FiniteElement(id, "四面体 (Tet4)") {}

    void computeStiffnessMatrix() override {
        std::cout << "  单元 [" << elementId << "] (" << elementType 
                  << ") -> 正在使用体积坐标精确解析法计算局部刚度矩阵..." << std::endl;
        // 里面是完全不同的四面体刚度计算逻辑...
    }
};

// ==========================================
// 业务调用端：体验"泛化"带来的多态威力
// ==========================================
int main() {
    std::cout << "=== 小米科技拓扑优化办公室 - 刚度组装模块启动 ===" << std::endl;

    // 1. 我们创建具体的子类对象
    HexahedronElement hex1(1001);
    TetrahedronElement tet1(1002);

    // 2. 【多态的魔法】：我们可以用"父类的指针"来统一管理所有的"子类对象"！
    std::vector<FiniteElement*> meshElements;
    meshElements.push_back(&hex1); // 子类对象的地址可以直接赋给父类指针
    meshElements.push_back(&tet1);

    std::cout << "\n--- 开始遍历网格，组装全局刚度矩阵 ---" << std::endl;

    // 3. 统一调用
    for (FiniteElement* elem : meshElements) {
        // 我们不需要知道指针指向的具体是六面体还是四面体
        // 只要调用 computeStiffnessMatrix()，C++ 会在运行时自动找到对应的正确方法！
        elem->computeStiffnessMatrix(); 
    }

    std::cout << "--- 组装完成 ---" << std::endl;

    return 0;
}

📝 本节小结：泛化关系的核心价值

当你在 UML 图中画出一个空心三角形（泛化关系）时，你不仅是在说明逻辑上的分类（苹果是一种水果），你更是向团队的 C++ 开发者传递了三个极具价值的架构决策：

┌─────────────────────────────────────────────────────────────┐
│  泛化关系 (Generalization)  =  继承 + 多态                    │
│                                                             │
│  1️⃣  代码复用：抽取共性，避免重复                            │
│  2️⃣  多态支持：统一接口，不同实现                            │
│  3️⃣  扩展性：符合开闭原则，新增子类不影响现有代码              │
└─────────────────────────────────────────────────────────────┘

架构决策	具体要求
提取共性	将通用属性抽到父类，避免重复代码
支持多态	使用 `virtual` 函数实现运行时绑定
虚析构函数	父类必须有 `virtual ~Base() = default;`

🎯 设计原则：看到泛化关系，就应该想到开闭原则——对扩展开放，对修改关闭。

🔜 接下来，让我们看看泛化关系的”灵魂伴侣”——实现关系。如果说泛化是”血脉传承”，那么实现就是”签署契约”。

终于来到了面向对象设计的最后一块、也是最具架构之美的拼图：实现关系（Realization）！

如果说”泛化（继承）”是父与子之间的**“血脉传承”（直接继承老子的真金白银和具体技能），那么”实现”就是类与接口之间的“签署契约”**（我答应你要完成这些任务，但我用我自己的方式去办）。

它表达的是一种 “遵守契约 (Obeys-a-contract)” 的关系。

1. UML 中的表示方法

在 UML 类图中，实现关系用一条带空心三角箭头的虚线来表示。

空心三角箭头：表明它和”泛化”是亲戚，都属于抽象层面的关系。
虚线：表明它比”泛化”要弱一些。它不继承具体的物理代码（血肉），只继承抽象的规则（灵魂）。
箭头永远指向接口类（通常带有 <<interface>> 构造型），另一端是具体的实现类。

2. 在 C++ 中的代码映射与逻辑本质

我们在最开始探讨 <<interface>> 时曾提到，C++ 没有 interface 关键字。因此，在 C++ 中，”实现关系”在语法结构上其实也是通过 public 继承来体现的。

但它的本质要求极其苛刻：

被继承的”父类”必须是一个纯抽象类（Pure Abstract Class）。这意味着：

它通常不包含任何成员变量（没有财产）。
它包含的所有业务函数必须是纯虚函数（virtual void doSomething() = 0;）（只有规定，没有实现）。
必须有一个虚析构函数。

**任何继承了这个接口的子类，都必须”强制交作业”**——重写所有的纯虚函数。哪怕少写一个，编译器都会报错，拒绝实例化这个子类。

3. 一个生动且详细的场景例子

我们以小米科技拓扑优化办公室的 小米工业软件的数据导出模块 为例。

概念理解：

拓扑优化完成后，底层的算法会得出一组材料密度（Density）数据。
我们需要把这些结果导出，供后处理软件进行 3D 渲染和查看。
这里的需求是多变的：有时候我们需要导出为专业的 VTK 格式（供 ParaView 查看），有时候为了方便调试，我们只需要导出简单的 Text 文本格式。
实现的体现： 我们定义一个纯粹的契约——**”结果导出器接口 (IResultExporter)”**。它规定”你必须能导出密度数据”。然后，VtkExporter 和 TextExporter 两个具体的类去**实现（Realization）**这个接口，各自写出自己格式的生成代码。

UML 类图：

classDiagram
    class IResultExporter {
        <>
        + exportDensityData(fileName: String, densities: vector) pure virtual
    }
    class VtkExporter {
        + exportDensityData(fileName: String, densities: vector) override
    }
    class TextExporter {
        + exportDensityData(fileName: String, densities: vector) override
    }
    IResultExporter <|.. VtkExporter : 实现关系
    IResultExporter <|.. TextExporter : 实现关系

C++ 代码实现：

#include <iostream>
#include <string>
#include <vector>

// ==========================================
// 接口 (Contract)：规定了行为，不包含任何实现
// ==========================================
class IResultExporter {
public:
    virtual ~IResultExporter() = default;

    // 纯虚函数 (标志就是后面的 = 0)
    // 这是一份必须遵守的契约：实现我的类，必须提供这个方法的具体代码！
    virtual void exportDensityData(const std::string& fileName, const std::vector<double>& densities) = 0;
};

// ==========================================
// 实现类 A：VTK 格式导出器
// ==========================================
class VtkExporter : public IResultExporter { // 语法上也是 public 继承
public:
    // 强制重写 (Override) 接口中的方法，履行契约
    void exportDensityData(const std::string& fileName, const std::vector<double>& densities) override {
        std::cout << "\n  [VTK 导出器] 正在生成 VTK 格式文件: " << fileName << ".vtu" << std::endl;
        std::cout << "  [VTK 导出器] 正在写入 " << densities.size() << " 个单元的密度数据..." << std::endl;
        
        // 渲染规范设定
        std::cout << "  [VTK 导出器] 配置渲染颜色表 (Lookup Table)：" << std::endl;
        std::cout << "               -> 颜色映射已校准：高 density 是红色的，低 density 是蓝色的。" << std::endl;
        std::cout << "  [VTK 导出器] 导出成功，可使用 ParaView 开启后处理。" << std::endl;
    }
};

// ==========================================
// 实现类 B：简单文本格式导出器
// ==========================================
class TextExporter : public IResultExporter {
public:
    void exportDensityData(const std::string& fileName, const std::vector<double>& densities) override {
        std::cout << "\n  [Text 导出器] 正在生成纯文本文件: " << fileName << ".txt" << std::endl;
        std::cout << "  [Text 导出器] 遍历数组，按逗号分隔写入纯数据..." << std::endl;
        std::cout << "  [Text 导出器] 导出成功，可使用 Notepad 或 Excel 打开。" << std::endl;
    }
};

// ==========================================
// 业务调用端：面向接口编程的巨大威力
// ==========================================
int main() {
    std::cout << "=== 拓扑优化计算完成，准备输出结果 ===" << std::endl;
    
    // 模拟计算生成的密度数据
    std::vector<double> finalDensities = {0.1, 0.9, 0.95, 0.05, 0.5};

    // 我们可以根据用户的配置，动态决定实例化哪一个具体的导出器
    // 但在整个主干逻辑中，我们只认"接口 (IResultExporter)"！
    
    IResultExporter* exporter1 = new VtkExporter();
    exporter1->exportDensityData("bracket_optimized", finalDensities);

    IResultExporter* exporter2 = new TextExporter();
    exporter2->exportDensityData("bracket_debug_data", finalDensities);

    delete exporter1;
    delete exporter2;

    return 0;
}

📝 本节小结：”实现”vs”泛化”的本质区别

对比维度	泛化 (Generalization)	实现 (Realization)
UML符号	`◁──` (实线+三角)	`◁..` (虚线+三角)
关系本质	血脉传承	签署契约
父类内容	有实现代码	纯虚函数，无实现
子类义务	可重写，也可直接用	必须实现所有纯虚函数
设计意图	代码复用 + 多态	定义规范 + 解耦
C++语法	`class Sub : public Base`	`class Impl : public IBase`

┌──────────────────────────────────────────────────────────────┐
│                                                              │
│   泛化 (Generalization)          实现 (Realization)          │
│   ━━━━━━━━━━━━━━━━━━━━━━         ━━━━━━━━━━━━━━━━━━━━━━      │
│                                                              │
│   "我是你的特殊版本"              "我承诺实现你的规范"        │
│                                                              │
│   👨‍👦 父亲 ──────→ 儿子           📜 契约 ──────→ 履约者      │
│       (给财产+技能)                    (只定规则，不给实现)    │
│                                                              │
└──────────────────────────────────────────────────────────────┘

💎 至理名言：在顶级软件架构（比如设计模式）中，有一句金科玉律——**”面向接口编程，而不是面向实现编程。”** UML 中的实现关系，就是这句话的灵魂体现。

🎉 恭喜你！ 到这里，UML类图中的6种核心关系你已经全部掌握了。接下来，让我们通过一个完整的速查表来回顾和巩固这些知识。

UML 类图核心关系与 C++ 架构映射全指南

本文档系统性地梳理了 UML 类图中最核心的 6 种对象间关系，以及接口和 Qt 属性的概念，并结合工业软件开发的业务场景，给出了具体的 C++ 物理映射方案。

1. 核心机制说明

1.1 接口 (`<<interface>>`)

UML 定义： <<interface>> 是一种标准构造型，表示只定义行为契约，不包含具体实现。
C++ 映射： 映射为包含且仅包含纯虚函数的抽象基类（通常包含一个 virtual 虚析构函数）。
架构意义： 明确传达”这是一个契约，请去实现它”的设计意图，是实现系统高内聚、低耦合（面向接口编程）的基础。

1.2 Qt 属性系统 (`Q_PROPERTY`)

概念机制： Qt 为了弥补 C++ 原生不支持反射的缺陷，引入了元对象系统（Meta-Object System）。
核心作用： 在 C++ 类的底层变量上开启一个标准化的动态数据接口。使得 QML 界面引擎、QPropertyAnimation 动画系统等，可以通过字符串名称（而不是强类型的指针调用）动态地读取、修改 C++ 对象的属性，并通过 NOTIFY 监听数据的实时变化。

2. UML 类图的 6 种核心关系

在面向对象架构设计中，类与类之间的耦合度按照 弱 -> 强 排序，依次为：

**依赖 (Dependency) < 关联 (Association) < 聚合 (Aggregation) < 组合 (Composition) < 实现 (Realization) = 泛化 (Generalization)**。

2.1 依赖关系 (Dependency) —— 临时借用

语义： “使用 (Uses-a)”。一个类在执行某个具体任务时，临时用到了另一个类的方法。用完即走，没有长期的生命周期绑定。被依赖类的修改可能会影响依赖类。
UML 符号： 虚线 + 开放箭头 （指向被依赖的类）。
C++ 映射： 通常体现为被依赖对象作为成员函数的局部变量、函数参数或返回值。绝不会作为成员变量长期存放。

2.2 关联关系 (Association) —— 平等认识

语义： “知道”。对象之间存在结构上的连接关系，彼此处于同一个运行环境中，但双方生命周期完全独立。
UML 符号： 实线 + 开放箭头 （单向关联）或 无箭头实线 （双向关联）。
C++ 映射： 通常体现为类中保存了另一个类的指针或引用。

2.3 聚合关系 (Aggregation) —— 松散组装

语义： “弱拥有 (Has-a)”。是关联关系的一种特例，表达”整体与部分”的概念。其核心在于部分可以脱离整体独立存在。整体不负责给部分分配内存，也不负责销毁部分。
UML 符号： 实线 + 空心菱形 （菱形在整体端）。
C++ 映射： 体现为类中保存了部分的指针或指针的集合（如 std::vector<Part*>）。析构时不调用 delete。

2.4 组合关系 (Composition) —— 同生共死

语义： “强拥有 (Contains-a)”。表达严格的整体与部分关系，部分不能脱离整体存在。整体全权负责部分的创建与销毁，生命周期严格一致。
UML 符号： 实线 + 实心菱形 （菱形在整体端）。
C++ 映射： 体现为直接的值类型成员变量，或在现代 C++ 中使用独占智能指针（std::unique_ptr），确保彻底的内存回收，防止内存泄漏。

2.5 泛化关系 (Generalization) —— 血脉传承

语义： “是一个 (Is-a)”。即面向对象中的”继承”。子类继承父类的属性和已有行为，并可利用虚函数实现多态。
UML 符号： 实线 + 空心三角箭头 （指向父类）。
C++ 映射： public 继承（例如 class Derived : public Base）。

2.6 实现关系 (Realization) —— 遵守契约

语义： “遵守约定 (Obeys-a-contract)”。类实现了接口中定义的纯行为契约。
UML 符号： 虚线 + 空心三角箭头 （指向带有 <<interface>> 的接口类）。
C++ 映射： 继承一个不包含任何成员变量、仅包含纯虚函数（= 0）的抽象基类，并 override 所有纯虚函数。

3. 关系对比与 C++ 物理映射速查表

UML 关系名称	UML 图形符号	耦合强度	核心逻辑 / 白话记忆	C++ 典型代码特征
依赖 (Dependency)	虚线 + 开放箭头 `- - - ->`	最弱	“临时借用” 我遇到困难时请你帮个忙，帮完你就可以走了。	存在于局部作用域：局部对象、方法参数、方法返回值。
关联 (Association)	实线 + 开放箭头 `──────>`	弱	“平等认识” 我知道怎么联系你，但我不对你的生死负责。	成员变量存放：裸指针 / 引用。
聚合 (Aggregation)	实线 + 空心菱形 `◇─────`	中等	“松散组装” 我是个团队，你加入了团队，但团队解散你还能活。	成员变量存放：指针集合 (析构函数中不负责 `delete`)。
组合 (Composition)	实线 + 实心菱形 `◆─────`	强	“同生共死” 你是我身体里不可分割的器官，我死了你也得死。	成员变量存放：对象实例或 `std::unique_ptr`。
泛化 (Generalization)	实线 + 空心三角 `─────▷`	极强	“血脉传承” 我是你的特殊化版本，继承你的全部财产和功能。	`class Sub : public Base {}` 继承带有实现代码的基类。
实现 (Realization)	虚线 + 空心三角 `- - - -▷`	极强	“履行契约” 你定规矩，我保证完成你交代的所有任务。	继承纯虚基类，并 `override` 实现所有纯虚函数。

本文作者： 迪丽惹Bug
本文链接： https://lyroom.github.io/2026/04/26/UML类图关系详解/
版权声明： 本博客所有文章除特别声明外，均采用 MIT 许可协议。转载请注明出处！

一文看懂UML的各种关系

一. UML有Java和C++之分吗

1. <<interface>> 是 UML 的标准，不是 Java 的专利

2. 在 Java 中的映射

3. 在 C++ 中的映射

其他常见的”语言映射”差异

二. 关联关系

1. UML 中的表示方法

2. 在 C++ 中的代码映射

3. 一个生动且详细的例子

概念理解：

UML 类图：

C++ 代码实现：

📝 本节小结

1. UML 中的表示方法

2. 在 C++ 中的代码映射与逻辑本质

3. 一个生动且详细的场景例子

概念理解：

UML 类图：

C++ 代码实现：

📝 本节小结：关联 vs. 聚合

1. UML 中的表示方法

2. 在 C++ 中的代码映射与逻辑本质

3. 一个生动且详细的场景例子

概念理解：

UML 类图：

C++ 代码实现（使用现代 C++ 的 std::unique_ptr）：

总结三者的进阶对比

📝 本节小结：三种”拥有”关系的递进

1. UML 中的表示方法

2. 在 C++ 中的代码映射与逻辑本质

3. 一个生动且详细的场景例子

概念理解：

UML 类图：

C++ 代码实现：

📝 本节小结：四种”横向”关系图谱

六. 泛化关系

1. UML 中的表示方法

2. 在 C++ 中的代码映射与逻辑本质

3. 一个生动且详细的场景例子

概念理解：

UML 类图：

C++ 代码实现：

📝 本节小结：泛化关系的核心价值

1. UML 中的表示方法

2. 在 C++ 中的代码映射与逻辑本质

3. 一个生动且详细的场景例子

概念理解：

UML 类图：

C++ 代码实现：

📝 本节小结：”实现”vs”泛化”的本质区别

UML 类图核心关系与 C++ 架构映射全指南

1. 核心机制说明

1.1 接口 (<<interface>>)

1.2 Qt 属性系统 (Q_PROPERTY)

2. UML 类图的 6 种核心关系

2.1 依赖关系 (Dependency) —— 临时借用

2.2 关联关系 (Association) —— 平等认识

2.3 聚合关系 (Aggregation) —— 松散组装

2.4 组合关系 (Composition) —— 同生共死

2.5 泛化关系 (Generalization) —— 血脉传承

2.6 实现关系 (Realization) —— 遵守契约

3. 关系对比与 C++ 物理映射速查表

1. `<<interface>>` 是 UML 的标准，不是 Java 的专利

C++ 代码实现（使用现代 C++ 的 `std::unique_ptr`）：

1.1 接口 (`<<interface>>`)

1.2 Qt 属性系统 (`Q_PROPERTY`)