如何在使用 Dagger/MVP 时管理演示者依赖项？答案

【问题标题】：How to manage presenter dependencies while using Dagger/MVP?如何在使用 Dagger/MVP 时管理演示者依赖项？
【发布时间】：2017-06-05 16:51:49
【问题描述】：

我有一个 Presenter，它有多个由 ApplicationComponent 提供的依赖项。现在我使用的一般模式是为演示者使用@Inject 构造函数。

但我有一个案例，演示者有大约 6 个依赖项。在这种情况下，构造函数注入仍然是最佳实践吗？在这种情况下，我发现构造函数变得非常笨拙。还有其他我想念的方式吗？

【问题讨论】：

你有 6 个依赖项的事实表明你的演示者做了太多的事情。现场注入只是将这一点隐藏在您的眼前。
你是对的。我现在明白了。

标签： android dagger-2 android-mvp

【解决方案1】：

正如EpicPandaForce 的评论，在 Presenter 中有很多依赖关系可能表明 Presenter 做得太多。事实上，在 MVP 中，Presenter 很容易退化为“上帝对象”。尽管如此，多参数构造函数似乎比具有 getter 和 setter 的可变类或属性注入更可取，正如评论中所述，它隐藏了依赖项的数量。

如果你不能重构你的 Presenter，例如，通过找到一个更高级别的抽象来依赖它，那么在 Effective Java by Joshua Bloch 的第 2 章中解决了由具有大量参数的构造函数引起的问题类型。

一种选择是将构造函数转换为构建器（有效的 Java 项目 2）。所以而不是：

public Foo(Bar bar, Baz baz, Zap zap) {
    this.bar = bar;
    this.baz = baz;
    this.zap = zap;
}

你有：

public class FooBuilder {
    private Bar bar;
    private Baz baz;
    private Zap zap;

    public FooBuilder setBar(Bar bar) {
        this.bar = bar;
        return this;
    }

    public FooBuilder setBaz(Baz baz) {
        this.baz = baz;
        return this;
    }

    public FooBuilder setZap(Zap zap) {
        this.zap = zap;
        return this;
    }

    public Foo createFoo() {
        return new Foo(bar, baz, zap);
    }
}

这只是您使用 Android Studio 的 Refactor/Replace constructor with builder 函数自动生成的构建器。

或者，您可以提取参数对象，但是这样做可能会违反得墨忒耳定律：

class FooParams {
    final Bar bar;
    final Baz baz;
    final Zap zap;

    FooParams(Bar bar, Baz baz, Zap zap) {
        this.bar = bar;
        //etc
    }
}

public Foo(FooParams fooParams) {
    this.fooParams = fooParams;
    fooParams.baz.doBazThings(); //etc
}

【讨论】：