在本例中，值和錯誤都傳遞給了訂閱服務器。需要記住的是，當使用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()));
}

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

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