Should I return CompletableFuture or Future when defining API?

In Java 8, is it better for interface or abstract class to define APIs returning CompletableFuture instead of returning Future ? Considering it is ugly converting Future to CompletableFuture and the fact that CompletableFuture will give the caller more flexibility of using functional style directly, what could be a good reason for an API to just return Future ?

---

My 2 cts:

by returning a Future, you keep your options open and can return a Future, or a CompletableFuture - it makes no difference from the caller's perspective.

by returning a CompletableFuture, you give the caller more options (they get more methods) but you also commit to returning that type of Future - if in two years you realise that returning a BetterFuture would make more sense, you will have to change the API, which is not good.

So you should probably assess the likelihood that you will want to return something other than a CompletableFuture in the future (haha) and decide accordingly.

---

Thought I would come back to this and provide some updates on my final decisions:

For my own code/design, I went with using CompletableFuture as the return type, because

this is a protected abstract method of an internal part that I want to make extensible;

I do not need an interface to define the binding;

the main purpose of this return type is a Future (for async IO), I personally feel the functional-styled API provided by CompletableFuture is an added benefit/reminder/encouragement of using functional style to the future devs.

With that being said, I would definitely use the CompletableStage interface as the return type, had I been designing a public API, because:

what @assylias and @Holger said about interface vs. realization and chaining ability

and the fact that CompletableStage has a method CompletableFuture<T> toCompletableFuture() .

链接地址: http://www.djcxy.com/p/89878.html

上一篇: 如何将印度语字符转换为Unicode转义字符

下一篇: 定义API时，我应该返回CompletableFuture还是Future？