菜单
在不提前过度抽象的前提下应用依赖注入与组合根设计。用于审查或重构对象创建边界、构造函数注入、类内部硬编码协作者、业务编排类偷偷创建服务、可测试性入口、C++ 具体类型 DI、composition root、constructor injection、concrete-type DI，以及关于“统一创建 + 依赖注入”“组合根”“控制反转”“依赖倒置”“避免过度抽象”“是否该抽接口/工厂/DI 容器”的问题。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | pragmatic-dependency-injection |
| description | 在不提前过度抽象的前提下应用依赖注入与组合根设计。用于审查或重构对象创建边界、构造函数注入、类内部硬编码协作者、业务编排类偷偷创建服务、可测试性入口、C++ 具体类型 DI、composition root、constructor injection、concrete-type DI，以及关于“统一创建 + 依赖注入”“组合根”“控制反转”“依赖倒置”“避免过度抽象”“是否该抽接口/工厂/DI 容器”的问题。 |
把对象装配放到系统边界，让业务编排类显式接收协作者；先用具体类型依赖注入，等真实变化压力出现后再抽接口。
这不是“所有类都要 DI”，也不是“DI 必须配接口和容器”。优先做最小但有架构收益的一步：把可替换、有生命周期、有外部资源或有测试压力的协作者，从类内部创建改为构造函数注入。
先分清两个角色：
main.cpp、CLI 入口、应用启动模块、测试 fixture。优先采用这种形状：
wxm::ThreadPool pool(threadCount, threadCount * 4, false, 1000);
FileWalker walker;
Hasher hasher;
DuplicateFinder finder(pool, walker, hasher);
避免让编排类同时负责创建协作者：
class DuplicateFinder {
FileWalker fileWalker_;
Hasher hasher_;
};
| 问题 | 倾向 |
|---|---|
| 协作者是否访问文件、网络、线程、时间、随机数、数据库、缓存或昂贵资源？ | 注入 |
| 协作者的配置、算法或实现选择是否属于外部策略？ | 注入 |
| 测试时是否希望换成内存实现、假对象或更可控的实例？ | 注入 |
| 这个对象是否只是函数内部的临时数据结构、值对象或算法细节？ | 内部创建 |
| 目前是否只有一个真实实现，而且测试不需要假实现？ | 注入具体类型，不急着抽接口 |
| 是否已经有多个实现、跨包稳定边界或真实 mock/fake 压力？ | 考虑窄接口 |
识别编排类。
决定注入边界。
先注入具体类型。
const 引用；小型不可变配置用值。延迟接口化。
IThing、工厂、注册表、服务定位器或 DI 容器。验证。
必需协作者由外部持有时，用这个形状作为起点：
class DuplicateFinder {
public:
DuplicateFinder(wxm::ThreadPool& pool,
const FileWalker& fileWalker,
const Hasher& hasher);
private:
wxm::ThreadPool& pool_;
const FileWalker& fileWalker_;
const Hasher& hasher_;
};
不要把临时对象传给会保存引用的构造函数。若协作者便宜、不可变、值语义清晰，优先按值保存。若协作者可选，显式建模为指针、std::optional 或更合适的类型，不要伪造“可空引用”。
不要把依赖注入当成框架问题。没有容器也可以有清晰的组合根。
不要把依赖倒置等同于立刻抽纯虚接口。具体类型 DI 已经能暴露对象边界、改善生命周期管理，并为后续接口化留下低成本路径。
不要把编排类改成万能参数收集器。若构造函数开始膨胀，优先检查类职责是否过大，或是否需要把一组稳定协作者组合成更高层服务。
不要为了测试把生产设计扭成全 mock。先问测试真正需要控制什么；能用真实轻量依赖时，不必制造假对象。
不要使用全局单例或服务定位器来“省构造参数”。这会把显式依赖重新藏回环境里。
分析类请求要说明：
实现类请求要说明：