[MediaForge] 架构之美：依赖倒置原则与好莱坞法则在微内核中的实战

在讨论微内核架构（Microkernel）和插件化编程时，一个经常被问到的直击灵魂的问题是："到底是核心（Core）依赖插件（Plugins），还是插件依赖核心？"

如果你的直觉是"核心需要调用插件，所以核心依赖插件"，那么你的架构在未来一定会走向"面条代码"的深渊。

本文将结合 C++ 音视频框架的实战，深度剖析**依赖倒置原则（Dependency Inversion Principle, DIP）和好莱坞原则（Hollywood Principle）**是如何在微内核架构中发挥魔力的。

---

一、 为什么核心不能依赖插件？

假设我们正在开发一个音视频渲染引擎，我们需要支持 H.264 编码和 NVIDIA 的硬件编码（Nvenc）。

传统的错误做法（正向依赖）

如果核心层（Core）直接依赖插件层（Plugins），代码通常是这样的：

// 在核心层 CoreEngine.cpp 中
#include "plugins/H264Encode.h"
#include "plugins/NvencEncode.h"

void VideoEngine::EncodeFrame() {
    if (useNvenc) {
        NvencEncode encoder;
        encoder.Encode(data);
    } else {
        H264Encode encoder;
        encoder.Encode(data);
    }
}

这种架构的灾难在于：

1. 牵一发而动全身：明天如果要加一个 Intel QuickSync 编码器，你必须修改核心层的代码，重新编译整个引擎。
2. 依赖污染：核心层被迫包含了 NVIDIA SDK 和 FFmpeg 的头文件。核心层变得无比臃肿，且容易因为第三方库的版本冲突而编译失败。

这严重违背了"开闭原则（OCP）"：对扩展开放，对修改关闭。

---

二、 依赖倒置（DIP）：让核心制定规矩

为了解决上述问题，我们需要引入依赖倒置原则（DIP）：

1. 高层模块（Core）不应该依赖于低层模块（Plugins）。两者都应该依赖于抽象（Interfaces）。
2. 抽象不应该依赖于细节，细节应该依赖于抽象。

1. 核心的特权：制定标准

我们将抽象接口（Interface）的所有权，牢牢抓在核心层手里。在 src/core/interfaces/ 目录下，我们定义 IVideoEncode：

// src/core/interfaces/IVideoEncode.h
class IVideoEncode {
public:
    virtual ~IVideoEncode() = default;
    virtual bool Encode(void* data) = 0; // 这是核心制定的规矩
};

2. 插件的宿命：服从规矩

插件代码必须跑到核心的领地去"拜码头"，包含核心的头文件，并严格实现核心要求的接口：

// src/plugins/encoder/NvencEncode.cpp
#include "core/interfaces/IVideoEncode.h" // 插件单向依赖核心

class NvencEncode : public IVideoEncode {
public:
    bool Encode(void* data) override {
        // 调用 NVIDIA API 进行硬件编码
        return true;
    }
};

架构解析 ：

此时，依赖的方向被完美地"倒置"了。原本是 Core 去找 Plugin，现在变成了 Plugin 必须死死抱住 Core 的大腿。Core 绝对不依赖 Plugins，它只认自己定下的 Interface。

---

三、 好莱坞原则："不要给我们打电话，我们会打给你"

既然核心不依赖具体的插件了，那核心怎么知道去哪里创建这些对象呢？这里就要用到微内核架构的另一个灵魂：好莱坞原则（Hollywood Principle）。

在好莱坞，群演（插件）把简历交给导演（核心）后，就只能回家等通知，绝不能主动跑去片场加戏。

1. 插件递交简历（注册机制）

插件在被 DLL 动态加载时，主动将自己的"创建图纸（工厂函数）"上交给核心的 PluginManager：

// 在 Nvenc 插件的 DLL 注入点
extern "C" __declspec(dllexport) void InitPlugin(PluginManager* pm) {
    // 递交简历：名字叫 Nvenc，这是我的创建方法
    pm->RegisterVideoEncoder("Nvenc", []() { 
        return std::make_shared<NvencEncode>(); 
    });
}

2. 核心翻牌子（延迟实例化）

核心引擎在运行到需要编码的环节时，向 PluginManager 要人，并直接调用：

// 在核心层的 VideoEngine.cpp 中
auto encoder = PluginManager::GetInstance().CreateVideoEncoder("Nvenc");
if (encoder) {
    encoder->Encode(data); // 核心只管发号施令，不管底层怎么干
}

---

四、 总结：微内核架构的终极壁垒

通过依赖倒置（DIP）和好莱坞原则，我们构建了一个固若金汤的微内核架构：

1. 物理隔离 ：插件在 CMake 编译时，必须反向链接 Core.lib。核心的 CMake 绝对不会扫描插件的源码。
2. 逻辑隔离 ：核心代码中没有任何具体的插件类名，只有 IVideo、IFilter 等抽象接口。
3. 团队解耦 ：架构师负责维护 core/interfaces/ 的纯洁性；外包团队或第三方开发者只需要拿着这些头文件，去开发独立的 DLL 即可。

这就解释了为什么在重构时，我们必须将那些看似属于插件的基类文件（如 IVideoEncode.cpp），强行从 plugins/ 目录搬回 core/interfaces/ 目录。因为制定标准的人，必须坐在核心的位置。