C#怎么实现依赖倒置原则 C# SOLID原则之DIP详解

依赖倒置原则要求高层模块和低层模块都依赖抽象，抽象不依赖细节；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 就白搭了。常见反模式：

CodeGeeX

智谱AI发布的AI编程辅助工具插件，可以实现自动代码生成、代码翻译、自动编写注释以及智能问答等功能

170

查看详情

• 在 Service 中 new Repository（应通过构造函数注入 IRepository）
• 工厂方法返回具体类型（应返回接口，且工厂本身也应被注入）
• 静态类调用具体服务（静态依赖无法替换，违反 DIP）

记住：只要某处出现了 new SomeConcreteClass()，就要问一句——这个类能不能换成接口？它的创建该不该交给外部？

抽象粒度要合适，避免过度设计

DIP 不是“所有东西都要抽象”。关键看是否真有多个实现、是否需要替换、是否影响可测性或可维护性。

• 一个接口只对应一类行为（遵循 ISP 接口隔离原则）
• 不要为“未来可能扩展”而提前抽象，先写具体逻辑，等出现第二个实现时再提炼接口
• 工具类（如 DateTime.Now、Path.Combine）不属于 DIP 范畴，它们是稳定的基础能力

基本上就这些。DIP 的本质不是写多少接口，而是把“谁负责创建、谁负责决定用哪个实现”这件事，从代码内部转移到更上层（如 Composition Root 或 DI 容器）。写得自然、改得轻松，才是它真正起效的时候。