用途
依赖倒置原则（Dependency Inversion Principle，DIP）技能用于在编写代码时约束依赖关系的组织方式。它针对的核心问题是：类在内部自行创建依赖（例如直接 new 出具体实现），导致高层策略与低层细节紧耦合。该技能主张高层模块不应依赖低层模块，二者都应依赖抽象；类应依赖接口而非具体实现；依赖应被注入，而不是在类内部实例化。
主要能力
- 识别违规：当类内部出现 new ConcreteService()、硬编码连接字符串或 API 密钥、直接 import 具体实现、构造函数没有外部依赖参数、无法脱离真实外部服务进行测试等“new 坏味道”时，判定为违反 DIP。
- 提供正确模式：先定义抽象接口，再通过构造函数注入实现，最后在组合根（composition root）处完成依赖装配。
- 压力抵抗协议：针对“别用 DI 搞复杂”“就一个依赖”“以后再重构”“生产环境才需要 DI”等常见借口，给出统一回应与行动建议。
- 测试收益说明：通过 mock 实现接口，可在不依赖真实 SendGrid、MySQL 等服务的情况下完成测试。
- 快速对照表：列出违规写法与正确写法的对应关系，例如 this.db = new MySQL() 对应 constructor(db: Database)。
使用方式
当需要创建任何使用外部服务的类时，按以下步骤执行：
- 为依赖定义接口（抽象）。
- 通过构造函数接收依赖，而不是在类内部实例化。
- 将接口的具体实现单独编写。
- 在组合根处创建具体实现并注入到高层模块。
技能中给出的示例结构为：定义 EmailService 与 UserRepository 接口；UserService 通过构造函数接收这两个依赖；SendGridEmailService 与 MySQLUserRepository 分别实现接口；最后在组合根中 new 出实现并传入 UserService。
适用场景
- 类使用数据库、邮件、文件系统、API 等外部服务。
- 在另一个类内部编写 new ConcreteClass()。
- 被要求“不要用 DI 把事情搞复杂”。
- 需要让代码可测试、可替换实现、避免高层策略与低层细节耦合。
限制
该技能是一项编码规范与指导，不提供具体的库、框架或安装命令。资料中未提供任何关于收费、价格、平台支持范围或性能效果的信息。技能本身不包含自动化检测工具，违规识别依赖开发者按清单人工判断。资料中未提供除示例代码之外的语言或框架适配说明。