依赖倒置原则要求高层模块和低层模块都依赖抽象,抽象不依赖细节;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 就白搭了。常见反模式:
版权声明:除非特别标注,否则均为本站原创文章,转载时请以链接形式注明文章出处。
还木有评论哦,快来抢沙发吧~