在本例中，值和錯誤都傳遞給了訂閱服務(wù)器。需要記住的是，當(dāng)使用CountDownLatch時，只有一個onError()或onComplete()被調(diào)用。因此，在錯誤和成功的情況下你都必須要釋放鎖。

可組合方法引用

正如你所想象的，任何嚴(yán)重依賴于lambdas的編程模型都容易受到“回調(diào)地獄”的影響。但是，具有一定的規(guī)范和方法引用，就不是問題了。所有明智的Ruby開發(fā)人員都會告訴你的是，小的私有方法(甚至只有一行程序!)在可讀性方面非常有價值。如果你很好地為方法命了名并使用方法引用語法，那么你就可以創(chuàng)建出非?？勺x的流。

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

在這個例子中，這個流就很易讀。為了獲得一個Flux，我們先從cloudFoundryClient和一個spaceId開始。我們使用這些去請求空間摘要,從這些空間摘要中提取應(yīng)用程序,然后將這些應(yīng)用程序映射到應(yīng)用程序概要。對于任何單獨(dú)的操作，我們不知道它具體是怎么做的，但我們并不需要知道這一點(diǎn)。如果需要，IDE很容易就能遍歷這些方法引用，而每個方法的代碼實現(xiàn)也不會混亂。

點(diǎn)自由風(fēng)格

在本文中，你可能已經(jīng)注意到我們使用了非常緊湊的風(fēng)格。 這叫做Pointfree style。它的主要好處是它幫助開發(fā)人員站在編寫函數(shù)(高層關(guān)注)的角度來思考，而不是擺弄數(shù)據(jù)(低層次的關(guān)注)。我們不會說在編寫響應(yīng)式編程時這是一個硬性要求，但是我們發(fā)現(xiàn)大多數(shù)人最終都更喜歡它。

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()));
}

如果你看一下這個例子，你會發(fā)現(xiàn)許多地方在分配變量、返回結(jié)果，通常這讓它看起來更像傳統(tǒng)的命令式代碼。而這，并不會增加它的可讀性。相反，添加更多的大括號、分號、等號和返回語句，雖然識別了數(shù)據(jù)來自哪里，希望能夠更加明確，但可能會混淆流本身實際的重點(diǎn)。

響應(yīng)式編程是一個巨大的課題，幾乎每個人都在開始接觸它。在編寫響應(yīng)式代碼時，“錯誤”的選擇非常少，但同時，大量的選擇會讓許多開發(fā)人員感到困惑，不知道什么是最好的入門方法。我們的意見來自于一個大型項目的經(jīng)驗，我們希望它能對你的響應(yīng)式之旅有所幫助，我們鼓勵你通過實驗來推動技術(shù)發(fā)展，并將你的發(fā)現(xiàn)回饋給社區(qū)。