解耦核心是依赖接口而非实现：定义纯虚接口（无成员变量、全virtual函数、virtual析构），业务类仅持接口指针/引用并由外部注入，实现类专注契约翻译，确保测试与替换无需修改业务代码。
业务代码直接 new 一个具体类（比如 new MySQLDatabase 或 new SerialPort），就是典型的依赖具体实现。这种写法会让编译、测试、替换全部卡死——换数据库？改三处；加个 Mock 测试？先重写构造逻辑。真正的解法不是“少写几行 new”，而是从设计源头切断高层对低层的硬引用。
定义纯虚接口类，不带任何实现细节
接口不是“功能列表”，而是稳定契约。它只声明行为，不暴露资源管理、平台差异或内部状态。
- 所有函数必须是
public+virtual+= 0，禁止提供默认实现 - 禁止在接口里定义成员变量（尤其是非静态、非 const 的）
- 析构函数必须是
virtual ~IRepository() = default;，否则多态删除会 UB - 避免模板化接口——它会把抽象变成编译期耦合，违背“运行时可替换”初衷
示例：IFileReader 只该有 Read() 和 Close()，不该有 m_bufferSize 或 Open(const std::string& path)（路径解析属于实现职责）。
业务类只持接口指针/引用，构造时由外部注入
业务类（比如 ReportGenerator）内部不能出现 new、std::make_unique 或任何具体类型名。它的依赖必须通过构造函数或 setter 传入。
- 首选构造函数注入：
ReportGenerator(std::unique_ptr<ifilereader> reader)</ifilereader> - 避免裸指针传递，除非明确生命周期由调用方完全控制
- 若需运行时切换实现（如根据配置选不同压缩算法），用
std::shared_ptr更安全 - 禁止在业务类内部做
dynamic_cast回具体类型——那说明接口定义漏了必要行为
错误示范：m_reader = std::make_unique<jsonfilereader>(path);</jsonfilereader> → 这行代码一写，就等于把 JSON 实现焊死在业务逻辑里。
实现类只负责一件事：把接口契约翻译成具体动作
实现类（如 TcpDataSource）是“翻译官”，不是“决策者”。它不决定流程顺序、不处理业务规则、不管理全局状态。
- 每个实现类只实现一个接口，不继承多个接口（避免胖接口）
- 资源获取（如 socket connect、文件 open）放在构造或
Init()中，失败应抛异常或返回错误码，而非静默失败 - 不要在实现类里 new 其他具体类——它自己就是被注入的一环
- 跨平台实现（如
WinSerialPort/LinuxSerialPort）必须共用同一接口，且行为语义一致（比如Read()超时逻辑要统一）
典型陷阱：SqliteRepository 在 Save() 里偷偷启动一个线程做异步写入——这违反了接口定义的同步语义，调用方无法预期行为。
测试和替换时，别碰业务类的 .cpp 文件
真正检验是否做到“依赖接口”，就看单元测试能不能不改一行业务代码，只换头文件和链接对象。
- 测试时用
FakeFileReader替代真实读取器，只需保证它继承IFileReader并实现同签名函数 - 集成测试切到网络版，只需把
TcpDataSource实例传给同一组业务类，无需重编译业务模块 - 如果某次修改导致
ReportGeneratorTest.cpp需要 include 新的实现头文件，说明接口层已泄漏 - 构建系统里，业务模块不应依赖具体实现的库（如
libmysqlclient），只 link 接口所在的轻量 stub 库
最难绷住的地方，往往在日志、错误码、超时配置这些“边缘需求”上——它们容易被塞进接口，结果让所有实现都得处理本不属于自己的逻辑。接口越薄，替换越稳。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
