依赖注入场景下：如何在IService实现类中使用Customer对象引用？

Great question! Let's walk through the best approaches here, based on standard dependency injection (DI) practices.

一、最优实现方式：构造函数注入 #

既然你的IService实现类始终需要调用Customer对象，这说明Customer是服务类的必填依赖——这种场景下，构造函数注入是当之无愧的最优选择。

为什么构造函数注入最好？ #

• 明确依赖关系：通过构造函数声明依赖，任何人阅读代码时都能立刻知道这个服务正常工作必须要有Customer实例。
• 不可变与安全：用readonly字段存储注入的Customer，避免依赖被意外修改，同时保证服务实例化时依赖就已就绪，不会出现运行时空引用异常。
• 符合DI核心原则：依赖注入的核心是解耦，构造函数注入让服务类不负责创建Customer实例，而是由DI容器（或上层代码）提供，便于后续替换Customer的实现（比如测试时用Mock）。

代码示例（C#为例） #

// 你的基础接口与类
public interface IService
{
    void Execute();
}

public class Customer
{
    public void ProcessOrder()
    {
        // Customer的业务逻辑实现
    }
}

// 最优实现：构造函数注入Customer
public class OrderService : IService
{
    private readonly Customer _customer;

    // 构造函数注入，强制传入Customer
    public OrderService(Customer customer)
    {
        _customer = customer ?? throw new ArgumentNullException(nameof(customer), "Customer实例不能为空");
    }

    public void Execute()
    {
        // 始终调用Customer的方法
        _customer.ProcessOrder();
        // 其他业务逻辑
    }
}

二、是否需要引入抽象类？ #

这取决于你IService接口有多少个实现类：

情况1：多个IService实现类都需要Customer依赖 #

如果有多个服务类（比如OrderService、PaymentService）都需要Customer实例，且它们有一些共享的调用Customer的逻辑，那么抽象基类能帮你减少重复代码，统一依赖注入逻辑。

代码示例

// 抽象基类处理Customer注入与共享逻辑
public abstract class BaseService : IService
{
    protected readonly Customer _customer;

    protected BaseService(Customer customer)
    {
        _customer = customer ?? throw new ArgumentNullException(nameof(customer));
    }

    // 共享的Customer调用逻辑
    protected void CommonCustomerAction()
    {
        _customer.ProcessOrder();
    }

    // 子类必须实现的核心方法
    public abstract void Execute();
}

// 子类继承基类，无需重复处理Customer注入
public class OrderService : BaseService
{
    public OrderService(Customer customer) : base(customer) { }

    public override void Execute()
    {
        CommonCustomerAction();
        // OrderService的专属逻辑
    }
}

public class PaymentService : BaseService
{
    public PaymentService(Customer customer) : base(customer) { }

    public override void Execute()
    {
        CommonCustomerAction();
        // PaymentService的专属逻辑
    }
}

情况2：只有一个IService实现类 #

如果当前只有一个服务类实现IService，引入抽象类完全是多余的——它只会增加不必要的层级复杂度，直接在服务类中用构造函数注入即可。

三、需要避免的错误方式 #

• 直接在服务类中new Customer：这会让服务类与Customer紧耦合，无法替换实例（比如测试时无法用Mock替代真实的Customer），完全违背了依赖注入的初衷。
• 属性注入：属性注入适合可选依赖（即没有该依赖服务也能正常工作），但你的场景中Customer是必须的，属性注入无法保证依赖被注入，容易引发运行时错误。

内容的提问来源于stack exchange，提问作者K.Z