依赖注入和构造函数疯狂修正

Question

阅读这个问题How to avoid Dependency Injection constructor madness? 后，我仍然对我的应用程序设计有些顾虑。假设我有一个类在其构造函数中接受很少的参数：

public class SampleViewModel
{
    public SampleViewModel(IReader1 reader1, IReader2 reader2, IReader3 reader3)
    {
        // ...
    }
}

IReaderX 是一个用于从不同来源检索数据的接口，如下所示：

public interface IReader1
{
    int Value1 { get; }

    string Value2 { get; }
}

现在，如果我想将这些接口聚合为一个，我将不得不创建另一个类，比如ReaderManager，它将充当底层类属性的包装器。很多管道代码。不好，如果你问我。

我尝试使用 Composition 并将所有阅读器作为 ReaderManager 类中的属性，但如果我试图在外部使用这些阅读器，则会违反得墨忒耳定律。

所以问题是：我应该如何减少不相互通信并且只公开属性而不是内部逻辑的构造函数依赖项的数量？

Answer 1

从几个不同的角度来看待它：消费者和更高层次的设计。

---

从`SampleViewModel`的角度来看

不喜欢有这么多合作者吗？也许如果它有它的druthers，它就只有一个合作者。那个合作者会是什么样子？为它创建一个interface to represent the role。

例如：

public interface ISampleViewModelReader
{
    int Value1    { get; }
    string Value2 { get; }

    double Value3 { get; }

    string Value4 { get; }
}

public class AggregatedSampleViewModelReader : ISampleViewModelReader
{
    public AggregatedSampleViewModelReader(IReader1 reader1, IReader2 reader2, IReader3 reader3)
    {
        // ...
    }
    // ...
    double Value3 { get { return reader2.Value3; } }
    // ...
}

public class SampleViewModel
{
    public SampleViewModel(ISampleViewModelReader reader)
    {
        // ...
    }
}

您表示您对这种方法有疑虑，因为它会涉及“大量管道代码”。但是考虑到这个管道代码将存在或不存在包装类。通过定义一个包装类，至少您确定了一个对象，其唯一职责是处理此管道，而不是将其混入SampleViewModel 的其他职责中。

---

从更高层次的设计角度

其他对象如何使用IReaderX 对象？ IReader1、IReader2和IReader3经常一起使用吗？ IReader1 和 IReader3 怎么样？

问这个问题的目的是识别“隐藏”的抽象，以便使它们更加明确。如果某些对象经常串联使用，它通常代表更广泛的设计理念。

但有时a rose is a rose is a rose。也许SampleViewModel 是唯一使用IReaderX 对象的东西。或许SampleViewModel 的唯一职责是聚合各个读者。在这些类型的情况下，拥有多个合作者并没有错。

如果稍后添加了另一个协作者（例如，IReader4），那么所有这些评估都应该重新进行。有时，设计只是碰巧在你身上跳出来。