依赖注入和观察者模式

Question

我发现我在代码中经常这样做（使用 Guice 作为我的 DI 框架）：

public class SomeObserver implements IObserver {
    @Inject
    SomeObserver(IObservable observable) {
        observable.subscribe(this);
    }
    // Snip
}

我最近想到，在测试时，我现在需要至少将一个模拟传递到我的程序中，这不一定是最糟糕的事情，但它确实取决于至少将依赖项绑定到该IObservable接口。另一种选择是在生产中执行以下操作：

public class SomeModule extends AbstractModule {
    // snip

    @Provides
    protected SomeObserver provideSomeObserver(IObservable observable) {
        SomeObserver newObject = new SomeObserver();
        newObject.subscribe(observable);
    }
}

然后在测试中，我什至不需要引用Observable. 但是，如果我想更改构造函数，则模块也必须更改（在第一个示例中没有更改）。

哪个更好？或者还有更好的第三种选择吗？

---

更新：我想谈谈我的用例。

考虑一个数据处理应用程序，其中数据源是 Observable。我不希望数据源了解系统的其他部分（关注点分离）。数据被过滤到至少三个不同的观察者中，他们从事独立的任务。我想保持数据源可交换 - 出于测试、关注点分离等原因，因此数据源只是实现我定义的接口Subscribable<Observer>，然后您可以调用.subscribe(this).

然后，我使用依赖项注入和模块来准确确定接线方式。如果我选择的话，这个解决方案还允许我装饰可观察量，使用注释来澄清注入。

因此，本质上，我使用依赖注入来管理连接，这正是我最初认为它的用途；比如说，创建一个ObservationManager看起来像是大量的样板文件却收效甚微。但同样，我可能错过了一些东西。

Answer 1

看起来您有点滥用依赖注入。

依赖注入，顾名思义，旨在通过解决类依赖关系来解决问题。但从语义上讲，观察者和可观察者并不相互依赖。它们确实不应该被视为依赖项。

设置观察者-可观察的关系本身就是一项单独的任务，因此理想情况下，您应该有一个依赖于观察者和可观察的第三个实体，并在它们之间建立关系。在这种情况下，使用事件总线看起来非常正交，因为它仍然归结为订阅，并且订阅应该在某个地方完成。

事实上，您已经注意到在这种情况下使用模拟很奇怪，这是一个信号，表明您试图将根本不是依赖项的东西用作依赖项。对于普通依赖项（由类直接使用），提供模拟对象是完全可以的，毕竟它们正是为此目的而设计的。