响应式API的设计、实现和应用

2018-03-20 17:01:48 InfoQ　点击量：评论 (0)

这篇文章来自于SpringOne的一个演讲。在过去的几年里，Java世界中在大力推动响应式编程的。无论是NodeJS开发人员使用非阻塞api的成功，还是

IllegalStateException())) .subscribe(System.out::println, t -> { t.printStackTrace(); latch.countDown(); }, latch::countDown); latch.await(); }

在本例中，值和错误都传递给了订阅服务器。需要记住的是，当使用CountDownLatch时，只有一个onError()或onComplete()被调用。因此，在错误和成功的情况下你都必须要释放锁。

可组合方法引用

正如你所想象的，任何严重依赖于lambdas的编程模型都容易受到“回调地狱”的影响。但是，具有一定的规范和方法引用，就不是问题了。所有明智的Ruby开发人员都会告诉你的是，小的私有方法(甚至只有一行程序!)在可读性方面非常有价值。如果你很好地为方法命了名并使用方法引用语法，那么你就可以创建出非常可读的流。

public Flux<ApplicationSummary> list() {
  return Mono
    .zip(this.cloudFoundryClient, this.spaceId)
    .flatMap(function(DefaultApplications::requestSpaceSummary))
    .flatMapMany(DefaultApplications::extractApplications)
    .map(DefaultApplications::toApplicationSummary);
}

在这个例子中，这个流就很易读。为了获得一个Flux，我们先从cloudFoundryClient和一个spaceId开始。我们使用这些去请求空间摘要,从这些空间摘要中提取应用程序,然后将这些应用程序映射到应用程序概要。对于任何单独的操作，我们不知道它具体是怎么做的，但我们并不需要知道这一点。如果需要，IDE很容易就能遍历这些方法引用，而每个方法的代码实现也不会混乱。

点自由风格

在本文中，你可能已经注意到我们使用了非常紧凑的风格。这叫做Pointfree style。它的主要好处是它帮助开发人员站在编写函数(高层关注)的角度来思考，而不是摆弄数据(低层次的关注)。我们不会说在编写响应式编程时这是一个硬性要求，但是我们发现大多数人最终都更喜欢它。

Mono<Void> deleteApplication(String name) {
  return PaginationUtils
    .requestClientV2Resources(page -> this.client.applicationsV2()
      .list(ListApplicationsRequest.builder()
        .name(name)
        .page(page)
        .build()))
    .single()
    .map(applicationResource -> applicationResource.getMetadata().getId())
    .flatMap(applicationId -> this.client.applicationsV2()
      .delete(DeleteApplicationRequest.builder()
        .applicationId(applicationId)
        .build()));
}

如果你看一下这个例子，你会发现许多地方在分配变量、返回结果，通常这让它看起来更像传统的命令式代码。而这，并不会增加它的可读性。相反，添加更多的大括号、分号、等号和返回语句，虽然识别了数据来自哪里，希望能够更加明确，但可能会混淆流本身实际的重点。

响应式编程是一个巨大的课题，几乎每个人都在开始接触它。在编写响应式代码时，“错误”的选择非常少，但同时，大量的选择会让许多开发人员感到困惑，不知道什么是最好的入门方法。我们的意见来自于一个大型项目的经验，我们希望它能对你的响应式之旅有所帮助，我们鼓励你通过实验来推动技术发展，并将你的发现回馈给社区。