[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"voidVideoEngine::EncodeFrame(){if(useNvenc){NvencEncode encoder;encoder.Encode(data);}else{H264Encode encoder;encoder.Encode(data);}}这种架构的灾难在于：
- 牵一发而动全身：明天如果要加一个 Intel QuickSync 编码器，你必须修改核心层的代码，重新编译整个引擎。
- 依赖污染：核心层被迫包含了 NVIDIA SDK 和 FFmpeg 的头文件。核心层变得无比臃肿，且容易因为第三方库的版本冲突而编译失败。
这严重违背了“开闭原则（OCP）”：对扩展开放，对修改关闭。
二、 依赖倒置（DIP）：让核心制定规矩
为了解决上述问题，我们需要引入依赖倒置原则（DIP）：
- 高层模块（Core）不应该依赖于低层模块（Plugins）。两者都应该依赖于抽象（Interfaces）。
- 抽象不应该依赖于细节，细节应该依赖于抽象。
1. 核心的特权：制定标准
我们将抽象接口（Interface）的所有权，牢牢抓在核心层手里。在src/core/interfaces/目录下，我们定义IVideoEncode：
// src/core/interfaces/IVideoEncode.hclassIVideoEncode{public:virtual~IVideoEncode()=default;virtualboolEncode(void*data)=0;// 这是核心制定的规矩};2. 插件的宿命：服从规矩
插件代码必须跑到核心的领地去“拜码头”，包含核心的头文件，并严格实现核心要求的接口：
// src/plugins/encoder/NvencEncode.cpp#include"core/interfaces/IVideoEncode.h"// 插件单向依赖核心classNvencEncode:publicIVideoEncode{public:boolEncode(void*data)override{// 调用 NVIDIA API 进行硬件编码returntrue;}};架构解析：
此时，依赖的方向被完美地“倒置”了。原本是 Core 去找 Plugin，现在变成了 Plugin 必须死死抱住 Core 的大腿。Core 绝对不依赖 Plugins，它只认自己定下的 Interface。
三、 好莱坞原则：“不要给我们打电话，我们会打给你”
既然核心不依赖具体的插件了，那核心怎么知道去哪里创建这些对象呢？这里就要用到微内核架构的另一个灵魂：好莱坞原则（Hollywood Principle）。
在好莱坞，群演（插件）把简历交给导演（核心）后，就只能回家等通知，绝不能主动跑去片场加戏。
1. 插件递交简历（注册机制）
插件在被 DLL 动态加载时，主动将自己的“创建图纸（工厂函数）”上交给核心的PluginManager：
// 在 Nvenc 插件的 DLL 注入点extern"C"__declspec(dllexport)voidInitPlugin(PluginManager*pm){// 递交简历：名字叫 Nvenc，这是我的创建方法pm->RegisterVideoEncoder("Nvenc",[](){returnstd::make_shared<NvencEncode>();});}2. 核心翻牌子（延迟实例化）
核心引擎在运行到需要编码的环节时，向PluginManager要人，并直接调用：
// 在核心层的 VideoEngine.cpp 中autoencoder=PluginManager::GetInstance().CreateVideoEncoder("Nvenc");if(encoder){encoder->Encode(data);// 核心只管发号施令，不管底层怎么干}四、 总结：微内核架构的终极壁垒
通过依赖倒置（DIP）和好莱坞原则，我们构建了一个固若金汤的微内核架构：
- 物理隔离：插件在 CMake 编译时，必须反向链接
Core.lib。核心的 CMake 绝对不会扫描插件的源码。 - 逻辑隔离：核心代码中没有任何具体的插件类名，只有
IVideo、IFilter等抽象接口。 - 团队解耦：架构师负责维护
core/interfaces/的纯洁性；外包团队或第三方开发者只需要拿着这些头文件，去开发独立的 DLL 即可。
这就解释了为什么在重构时，我们必须将那些看似属于插件的基类文件（如IVideoEncode.cpp），强行从plugins/目录搬回core/interfaces/目录。因为制定标准的人，必须坐在核心的位置。