依赖倒置原则要求高层模块和低层模块都依赖抽象，抽象不依赖细节；C#中通过接口/抽象类定义契约、构造函数注入及DI容器实现，避免内部new具体类，抽象应基于实际多实现需求。
依赖倒置原则（Dependency Inversion Principle，DIP）是 SOLID 五大原则中的第四个，核心就一句话：高层模块不应该依赖低层模块，二者都应该依赖抽象；抽象不应该依赖细节，细节应该依赖抽象。在 C# 中，它不是靠语法强制的，而是通过合理设计接口、抽象类和依赖注入来落地的。
用接口或抽象类定义契约，而不是具体类
这是 DIP 最直接的体现。比如你有一个订单服务（高层模块），它需要发邮件通知用户（低层模块）。如果直接 new MailService()，那就紧耦合了。
❌ 错误写法：直接依赖具体实现public class OrderService
{
private readonly MailService _mailService = new MailService(); // 依赖具体类
public void ProcessOrder() { … _mailService.Send(); }
}✅ 正确写法：依赖抽象（接口）public interface INotificationService
{
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 实现// Program.cs 或 Startup.cs
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 容器）。写得自然、改得轻松，才是它真正起效的时候。
以上就是C#怎么实现依赖倒置原则 C# SOLID原则之DIP详解的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1442829.html
微信扫一扫 
支付宝扫一扫 
