构造函数注入，避免非依赖参数

Question

我需要重构现有的抽象类来实现依赖注入，但是这个类有两个接受其他参数的构造函数。

public abstract class MyClassBase
{
    MyClassBase(int settingId)
    {
        _settingId = settingId;
    }

    MyClassBase(Setting setting)
    {
        _setting = setting;
    }
    ...
}

我需要注入一些接口，并避免在构造函数中传递任何其他参数，如“settingsId”和“Setting”。所以我的想法是在创建此类的实例后创建两种方法来设置这些参数。

public abstract class MyClassBase
{
    private readonly IOneService _oneService;
    private readonly ITwoService _twoService;

    MyClassBase(IOneService oneService, ITwoService twoService)
    {
        _oneService = oneService;
        _twoService = twoService;
    }

    protected void SetupSetting(int settingId)
    {
        _settingId = settingId;
    }

    protected void SetupSetting(Setting setting)
    {
        _setting = setting;
    }

    protected Setting Setting
    {
        get 
        {
            if(_setting == null)
            {
                _setting = _oneService.getSettingById(_settingId);
            }

            return _setting;
        }
    }  
}

但它看起来不是一个合适的解决方案，因为如果开发人员忘记在创建实例后运行这些方法之一，我们将来可能会得到一个异常（对象未设置为引用...）。我应该如何正确执行此操作？

Answer 1

不。您应该从依赖接口获取所有需要的数据。比如：

MyClassBase(IOneService oneService, ITwoService twoService, ISettings set)
{
    _setting = set;
    ....
}

Answer 2

你的injectables应该只有一个构造函数。拥有多个构造函数是一种反模式。该类需要运行的所有内容都必须通过构造函数传入；使用多个步骤构建对象会导致时间耦合，这是一种设计味道。

所以总的来说，我同意@realnero的解决方案，尽管用接口抽象Settings对象可能没有什么用处。接口旨在抽象行为，但此类设置对象通常只包含数据，而不包含行为。因此，添加抽象将不起作用。

尽管注入 Settings 对象可能很好，但此类对象经常被误用。您不应该传入构造函数，而不是此类直接需要本身。如果 Settings 对象包含整个应用程序的值，则此类需要哪些值将变得不清楚。它还会导致您在每次配置更改时更改 Settings 对象，并且将有许多使用者依赖于这个不断增长的 Settings 类。

这些设置类通常用于调度到配置文件。换句话说，当使用者从 Settings 类请求值时，它会查询配置文件。这将导致配置文件被延迟读取。这使得应用程序在运行时很容易失败，因为配置文件中的拼写错误。相反，您宁愿希望应用程序在启动时直接失败（快速失败）。

因此，您应该只注入此类组件所需的配置值，并且应该在应用程序启动时从配置文件中读取这些值。这允许应用程序在配置不正确时快速失败，非常清楚组件需要什么，并防止您拥有整个应用程序所依赖的中央配置类。

但是拥有具有依赖关系的基类本身就是一种代码气味。没有具体的例子，就不可能说如何重构，但是我认为有两个设计错误导致了基类的使用。

开发人员经常将横切关注点移动到基类中。这将导致这些基类增长并变得难以维护，并导致基类的复杂性与派生类交织在一起，使它们变得复杂且难以测试。相反，应该使用装饰或拦截来添加横切关注点。装饰器设计模式在应用横切关注点时非常有效。它允许服务根本没有基类，并在添加新的横切关注点时提供了很大的灵活性。例如，看看这篇文章，了解一些关于这个的想法。

如果基类不处理横切问题，而是处理许多派生类重用的中央应用程序逻辑，那么将基类逻辑抽象为单独的服务通常是更好的方法。在执行此操作时，可以将此新服务注入到组件中，这允许组件忽略此新服务本身的依赖关系。它可以避免您必须传入基类的依赖项并调用基构造函数。其中一种方法是使用聚合服务。