依赖倒置原则要求高层模块和低层模块都依赖抽象，抽象不依赖细节；C#中通过接口/抽象类定义契约、构造函数注入及DI容器实现，避免内部new具体类，抽象应基于实际多实现需求。
依赖倒置原则（Dependency Inversion Principle，DIP）是 SOLID 五大原则中的第四个，核心就一句话：高层模块不应该依赖低层模块，二者都应该依赖抽象；抽象不应该依赖细节，细节应该依赖抽象。在 C# 中，它不是靠语法强制的，而是通过合理设计接口、抽象类和依赖注入来落地的。
用接口或抽象类定义契约，而不是具体类
这是 DIP 最直接的体现。比如你有一个订单服务（高层模块），它需要发邮件通知用户（低层模块）。如果直接 new MailService()，那就紧耦合了。
- ❌ 错误写法：直接依赖具体实现
{
private readonly MailService _mailService = new MailService(); // 依赖具体类
public void ProcessOrder() { ... _mailService.Send(); }
}
- ✅ 正确写法：依赖抽象（接口）
{
void Send(string message);
}
public class MailService : INotificationService { ... }
public class SmsService : INotificationService { ... }
public class OrderService
{
private readonly INotificationService _notification;
public OrderService(INotificationService notification) => _notification = notification;
public void ProcessOrder() { ... _notification.Send(...); }
}
构造函数注入是主流实践
C# 中最常用、最符合 DIP 的方式就是构造函数注入（Constructor Injection）。它让依赖关系显式、可测试、易替换。
- 依赖由外部传入，类本身不负责创建依赖实例
- 配合 .NET 内置的 DI 容器（如 IServiceCollection），注册和解析自动完成
- 单元测试时可轻松传入 Mock 实现
builder.Services.AddScoped
// 或切换为短信通知
// builder.Services.AddScoped
避免在类内部 new 抽象的实现类
即使你用了接口，如果还在类里 new 具体实现，DIP 就白搭了。常见反模式：
- 在 Service 中 new Repository（应通过构造函数注入 IRepository）
- 工厂方法返回具体类型（应返回接口，且工厂本身也应被注入）
- 静态类调用具体服务（静态依赖无法替换，违反 DIP）
记住：只要某处出现了 new SomeConcreteClass()，就要问一句——这个类能不能换成接口？它的创建该不该交给外部？
抽象粒度要合适，避免过度设计
DIP 不是“所有东西都要抽象”。关键看是否真有多个实现、是否需要替换、是否影响可测性或可维护性。
- 一个接口只对应一类行为（遵循 ISP 接口隔离原则）
- 不要为“未来可能扩展”而提前抽象，先写具体逻辑，等出现第二个实现时再提炼接口
- 工具类（如 DateTime.Now、Path.Combine）不属于 DIP 范畴，它们是稳定的基础能力
基本上就这些。DIP 的本质不是写多少接口，而是把“谁负责创建、谁负责决定用哪个实现”这件事，从代码内部转移到更上层（如 Composition Root 或 DI 容器）。写得自然、改得轻松，才是它真正起效的时候。
