通过Java 8中的Applicative Builder组合多个异步结果

几个月前，我发布了一个出版物 ，在其中详细解释了我提出的名为Outcome的抽象，它通过强制使用语义帮助了我很多 没有副作用的代码。 通过遵循这种简单（但功能强大）的约定，我最终将任何类型的故障（又称Exception）都转化为函数的显式结果，从而使一切都更容易推论。 我不认识您，但是我厌倦了处理会破坏一切的异常，因此我做了一些事情，老实说，它确实工作得很好。 因此，在继续讲故事之前，我真的建议您仔细阅读该文章。 现在，让我们使用古怪的应用思想解决一些异步问题，对吧？

这样邪恶的事情来了

生活真的很好，我们的编码像往常一样快，更清晰和可组合，但是，出乎意料的是，我们偶然发现了“缺失”功能（请大笑一下）：我们需要在一个非同步状态下合并多个异步 结果实例阻碍时尚…。

受到这个想法的鼓舞，我开始工作。 我尝试了很多时间，以寻求一种健壮而又简单的方式来表达这种情况。 虽然新的ComposableFuture API原来比我期望的要好得多（尽管我仍然不明白为什么他们决定使用诸如applyAsync或thenComposeAsync之类的名称，而不是map或flatMap ），但我总是最终实现时过于冗长和重复我在Scala上所做的一些事情，但是经过很长的“ Mate ”课程之后，我有了“嘿！ 一刻”：为什么不使用类似于应用程序的内容 ？

问题

假设我们有两个异步结果：

CompletableFuture<Outcome<String>> textf = 
    completedFuture(maybe("And the number is %s!"));

CompletableFuture<Outcome<Integer>> numberf = 
    completedFuture(maybe(22));

还有一个愚蠢的实体Message：

public static class Message{

    private final String _text;
    private final Integer _number;

    private Message(String msg, Integer number){
        _text = msg;
        _number = number;
    }

    public String getContent(){
        return String.format(_text,_number);
    }
}

我需要给定textf和numberf的东西，它会给我类似的东西

//After combining textf and numberf
CompletableFuture<Outcome<Message>> message = ....

所以我给圣诞老人写了一封信：

1. 我想仅当两个值都可用时才使用numberf返回的数字异步格式化textf返回的字符串，这意味着两个期货均成功完成，并且所有结果均未失败。 当然，我们需要不 阻塞。
   
2. 如果发生故障，我想收集在执行textf和/或numberf期间发生的所有故障，然后再次将它们返回给调用方，而不会阻塞。
3. 我不想受到要组合的值数的限制，它必须能够处理大量的异步结果。 我是说没有阻止吗？ 你去...
4. 尝试期间不死。

适用于救援人员

如果您考虑一下，那么一种简单的方法来表达我们想要实现的目标如下：

// Given a String -> Given a number -> Format the message
f: String -> Integer -> Message

检查f的定义，它表示类似：“给出一个String ，我将返回一个以Integer作为参数的函数，该函数在应用时将以这种方式返回Message类型的实例，而不是等待所有值一次可用，我们可以一次部分应用一个值，以获得对Message实例构造过程的实际描述。 听起来不错。

要实现这一点，如果我们可以使用构造lambda Message：new并对其进行咖喱 ，再说一次，boom！，done !，将是非常了不起的，但是在Java中这是不可能的（以一种通用，美观和简洁的方式进行），因此对于为了我们的示例，我决定采用我们钟爱的Builder模式，该模式确实可以胜任：

public static class Builder implements WannabeApplicative<Message> {

    private String _text;
    private Integer _number;

    public Builder text(String text){
        _text=text;
        return this;
    }

    public Builder number(Integer number){
        _number=number;
        return this;
    }

    @Override
    public Message apply() {
        return new Message(_text,_number);
    }
}

这是WannabeApplicative <T>的定义：

public interface WannabeApplicative<V>
{
    V apply();
}

Disclamer ： 对于那些功能 怪癖 ，这本身并不是适用的，我知道，但是我从中汲取了一些想法，并根据语言提供给我的工具对其进行了调整。 因此，如果您感到好奇，请查看此帖子以获取更正式的示例。

如果您仍在我身边，我们可以同意，到目前为止，我们并没有做过任何复杂的事情，但是现在我们需要表达一个构建步骤，记住，该步骤必须是无阻塞的，并且能够合并以前发生的任何故障可能发生在其他可能有新执行的处决中。 因此，为了做到这一点，我提出了以下内容：

public static class CompositionSources<B>
{
    private CompositionSources(){ }

    public interface Partial<B>
    {
        CompletableFuture<Outcome<B>> apply(CompletableFuture<Outcome<B>> b);
    }

    public interface MergingStage<B, V>{
        Partial<B> by(BiFunction<Outcome<B>, Outcome<V>, Outcome<B>> f);
    }

    public <V> MergingStage<B, V> value(CompletableFuture<Outcome<V>> value){

        return f -> builder
                 -> builder.thenCombine(value, (b, v) -> f.apply(b, v)
                                                          .dependingOn(b)
                                                          .dependingOn(v));
    }

    public static <B> CompositionSources<B> stickedTo(Class<B> clazz)
    {
        return new CompositionSources<>();
    }
}

首先，我们有两个功能接口：一个是Partial <B> ，它表示将值懒惰地应用于生成器 ，而第二个接口MergingStage <B，V>表示“如何”组合既是建设者又是价值 。 然后，我们得到了一个名为value的方法，给定类型为CompletableFuture <Outcome <V >>的实例，它将返回类型为MergingStage <B，V>的实例，并且信不信由你，这就是发生魔术的地方。 如果您还记得MergingState定义， 则将看到它是BiFunction ，其中第一个参数的类型为Outcome <B> ，第二个参数的类型为Outcome <V> 。 现在，如果遵循这些类型，则可以说出两件事：一侧的构建过程的部分状态（类型参数B）和需要应用于构建器当前状态的新值（类型参数V），以便在应用时将生成一个新的构建器实例，该实例具有“构建顺序中的下一个状态”，由Partial <B>表示 。 最后但并非最不重要的一点，我们有stickedTo方法，它基本上是一个（糟糕的Java）技巧，可在定义构建步骤时坚持使用特定的应用程序类型（构建器）。 例如，具有：

CompositionSources<Builder> sources = CompositionSources.stickedTo(Builder.class);

我可以为任何Builder实例定义部分值应用程序，如下所示：

//What we're gonna do with the async text when available
Partial<Builder> textToApply = 
    sources.value(textf)
            .by((builder, text) -> builder.flatMapR(b -> text.mapR(b::text)));

//Same thing for the number
Partial<Builder> numberToApply = 
    sources.value(numberf)
            .by((builder, number) -> builder.flatMapR(b -> number.mapR(b::number)));

看到我们还没有建立任何东西，我们只是描述了当时间到时我们想对每个值进行的操作 ，我们可能想在使用新值之前进行一些验证（这是在结果发挥重要作用时），或者只是使用确实如此，这完全取决于我们，但主要要点是我们还没有应用任何东西。 为了这样做，并最终收紧所有松散的末端，我想出了其他一些定义，如下所示：

public static class FutureCompositions<V , A extends WannabeApplicative<V>>{

    private final Supplier<CompletableFuture<Outcome<A>>> _partial;

    private FutureCompositions(Supplier<CompletableFuture<Outcome<A>>> state)
    {
        _partial=state;
    }

    public FutureCompositions<V, A> binding(Partial<A> stage)
    {
        return new FutureCompositions<>(() -> stage.apply(_partial.get()));
    }

    public CompletableFuture<Outcome<V>> perform()
    {
        return _partial.get().thenApply(p -> p.mapR(WannabeApplicative::apply));
    }

    public static <V, A extends WannabeApplicative<V>> FutureCompositions<V, A> begin(A applicative)
    {
        return new FutureCompositions<>(() -> completedFuture(maybe(applicative)));
    }
}

希望这不是那么令人头疼，但我会尽力将其分解得尽可能清楚。 为了开始指定如何将整个事物组合在一起，您将从调用WannabeApplicative <V>类型的实例开始 ，在我们的示例中，它的类型参数V等于Builder 。

FutureCompositions<Message, Builder> ab = begin(Message.applicative())

看到，在调用begin之后 ，您将获得一个FutureCompositions的新实例，其中包含一个延迟评估的部分状态 ，使其成为整个构建过程状态的唯一所有者，而这正是我们所做的一切的最终目标到目前为止，我们已经做好了充分的控制，以完全控制何时以及如何将事物组合在一起。 接下来，我们必须指定要合并的值，这就是绑定方法的用途：

ab.binding(textToApply)
  .binding(numberToApply);

这样，我们便可以使用先前定义的Partial实例为构建器实例提供所有需要合并的值，以及每个实例应该发生的情况的规范。 还可以看到，所有内容仍在惰性评估中，什么都没有发生，但是我们仍然堆叠了所有“步骤”，直到最终确定实现结果为止，这将在您调用perform时发生。

CompletableFuture<Outcome<Message>> message = ab.perform();

从那一刻起，一切都会展开，每个构建阶段都将得到评估，可以在结果实例中返回并收集故障，或者简单地将新可用的值以一种或另一种方式提供给目标构建器实例，所有步骤将被执行直到什么都不做。 我将尝试描述如下情况

如果您注意图片的左侧，您可以轻松地看到我之前显示的每个步骤是如何“定义的”，遵循先前的“声明”箭头方向，即您实际描述构建过程的方式。 现在，从您调用perform的那一刻起，每个应用实例（在我们的情况下，请记住Builder ）将以相反的方向被懒惰地求值：它将从求值堆栈中的最后一个指定阶段开始，然后继续求值下一个阶段依次类推，直到达到建筑物定义的“起点”，它将开始展开或向上逐步展开评估，并使用MergingStage规范收集所有信息。

而这仅仅是个开始…。

我敢肯定，可以做很多事情来改善这个想法，例如：

• 连续两次调用CompositionSources.values（）的 dependingOn 很烂 ，我觉得这太冗长了，我必须对此做些事情。
• 我不太确定要继续将结果实例传递给MergingStage ，如果在调用它之前解开要合并的值并只返回Either <Failure，V> ，它将看起来更干净，更轻松-这将降低复杂性并提高灵活性关于幕后发生的事情。
• 尽管使用Builder模式完成了这项工作，但是感觉还是很老套了 ，我很想轻松地构造函数，因此在我的待办事项清单中是检查jOOλ或Javaslang是否可以提供某些服务。
• 更好的类型推断，以便从代码中消除任何不必要的干扰，例如， stickedTo方法，它的确是代码的味道，我一开始就讨厌。 绝对需要更多时间来找出从定义本身推断应用类型的另一种方法。

非常欢迎您给我发送您可能有的任何建议和意见。 干杯，记住……

翻译自: https://www.javacodegeeks.com/2015/12/composing-multiple-async-results-via-applicative-builder-java-8.html