При создании API это хорошая практика для кодирования интерфейса, поэтому кажется, что возвращение CompletionStage кажется наилучшим подходом. Однако я понял, что я всегда звоню. Дополняю Future после получения CompletionStage. Каков рекомендуемый подход в этом случае?Должен ли API возвращаться CompletionStage или CompletableFuture
API, использующий CompletionStage, предназначен для неблокирующего использования, поэтому вызов .toCompletableFuture() требуется только в том случае, если вызывающий абонент не работает неблокирующим способом. Если API не является неблокирующим, он должен вернуть обычный старый интерфейс Future.
См. Также вопрос с обратной стороны https://stackoverflow.com/q/34930840/1531945 –
Смотрите мой ответ на https://stackoverflow.com/a/49158702/1113842
Как спросил Holger, почему вы звоните toCompletableFuture?
complete/cancel это сделать? Большинство приложений предоставляют свои собственные механизмы для завершения этапа. Таким образом, нет необходимости раскрывать эти методы.get? Этого следует избегать при асинхронном программировании.Если ответы не совпадают с обоими вопросами, вы должны вернуть CompletionStage.
Это зависит от * почему * вы всегда вызываете 'toCompletableFuture()' ... – Holger
@Holger Можете ли вы подробно остановиться на этом? Мы вызываем toCompletableFuture, чтобы мы могли вызывать методы, которые доступны только в нем. Это немного запутывает, когда мы можем получить конкретный пример из интерфейса. Они тесно связаны и побеждают цель иметь интерфейс. – Mayumi
Ну, 'CompletionStage' определяет 38 методов, интерфейс' Future' определяет еще пять. Если вы постоянно («всегда») нуждаетесь в оставшихся восьми, специальных методах «CompletableFuture», кодирование с интерфейсом действительно не для вас. – Holger