11

CompletableFutureJava 8 では、インターフェイスまたは抽象クラスは、返す代わりに返すAPI を定義する方が良いFutureですか? への変換が醜いことFutureCompletableFutureと、呼び出し元が関数型スタイルを直接使用する柔軟性を高めるという事実を考慮するCompletableFutureと、API が単に を返す正当な理由は何Futureでしょうか?

4

2 に答える 2

3

私はこれに戻って、私の最終決定についていくつかの最新情報を提供すると思いました:

私自身のコード/設計ではCompletableFuture、戻り値の型として使用しました。

  • これはprotected abstract拡張可能にしたい内部部分のメソッドです。
  • バインディングを定義するためのインターフェイスは必要ありません。
  • この戻り値の型の主な目的は Future (非同期 IO 用) です。個人的には、によって提供される関数型スタイルの APICompletableFutureは、将来の開発者に関数型スタイルを使用することの追加の利点/リマインダー/奨励であると感じています。

そうは言ってもCompletableStage、パブリック API を設計していた場合、次の理由から、間違いなくインターフェイスを戻り値の型として使用します。

  • @assylias と @Holger がインターフェース対実現と連鎖能力について語ったこと
  • CompletableStageそしてメソッドを持っているという事実CompletableFuture<T> toCompletableFuture()。
于 2016-01-27T18:30:37.250 に答える
2

私の2カラット：

  • Future を返すことで、オプションを開いたままにし、Future または CompletableFuture を返すことができます。呼び出し元の観点からは違いはありません。
  • CompletableFuture を返すことで、呼び出し元により多くのオプションを与える (より多くのメソッドを取得する) だけでなく、そのタイプの Future を返すことにもコミットします。2 年後に、BetterFuture を返す方が理にかなっていることに気付いた場合は、API を変更する必要があります。 、これは良くありません。

したがって、将来 CompletableFuture 以外のものを返す可能性を評価し (笑)、それに応じて決定する必要があります。

于 2016-01-21T18:17:57.253 に答える