用于不同Rx源的通用RxJava2变换器

时间:2017-07-15 21:54:13

标签: java android interface rx-java abstraction

我意识到这可能属于库设计和功能实现的范围,但是想问一下我们是否可以在不同的源上使用Transformers(例如Observable和Completable),因为它们共享了很多方法,特别是副作用。我们不是通过扩展它们来创建我们自己的运算符,而是创建了变换器来处理我们通常用于观察和补充的逻辑。

例如,我们已经为它创建了Transformer函数,而不是在订阅调用中包装返回的一次性函数:

public static <T> ObservableTransformer<T, T> dispose(CompositeDisposable compositeDisposable) {
    return observable -> observable.doOnSubscribe(compositeDisposable::add);
}

现在,这不会对除Observable之外的任何其他来源起作用,我们需要为可补充的

添加另一种方法
public static CompletableTransformer disposeCompletable(CompositeDisposable compositeDisposable) {
    return completable -> completable.doOnSubscribe(compositeDisposable::add);
}

这已成为围绕处理两种不同来源变换器的模式,这些变换器具有完全相同的方法

例如

public static <T, V extends Progressive & Erroneous> ObservableTransformer<T, T> progressiveErroneous(V view) {
    return observable -> observable
        .compose(progressive(view))
        .compose(erroneous(view));
}

public static <V extends Progressive & Erroneous> CompletableTransformer progressiveErroneousCompletable(V view) {
    return observable -> observable
        .compose(progressiveCompletable(view))
        .compose(erroneousCompletable(view));
}

对于这些,我们必须实施progressiveCompletable(view)erroneousCompletable(view),方法正文没有区别。

我们还希望从控制器中删除测试,只测试这些变换器在视图接口上调用正确的方法。这将大大减少冗余测试,这就是我们选择这种抽象设计的原因。但是,如果我们继续复制这样的方法,测试将是非常重复的。如果我们开始使用其他来源,如Flowable,Maybe等,它只会变得更糟

我们有什么办法可以使用抽象变换器来操作支持常见操作的源,例如

  • doOnSubscribe
  • doOnError
  • doFinally

0 个答案:

没有答案