【问题标题】:Generic help defining the interface定义接口的通用帮助
【发布时间】:2020-03-05 07:55:47
【问题描述】:

我有一组 API,我正在使用 project-reactor 为其创建反应式版本

我现有的界面类似于

  Profile getProfile(String accessToken);

  Profile getProfileByEmail(String adminToken, String email);

  Token validateToken(String accessToken);
  ...

项目反应堆变体将是

  Mono<Profile> getProfile(String accessToken);

  Mono<Profile> getProfileByEmail(String adminToken, String email);

  Mono<Token> validateToken(String accessToken);
  ...

另一个变种是

  CompletableFuture<Profile> getProfile(String accessToken);

  CompletableFuture<Profile> getProfileByEmail(String adminToken, String email);

  CompletableFuture<Token> validateToken(String accessToken);
  ...

我想为上述这些 API 使用泛型定义一个超级接口。

任何关于如何定义接口而不必处理未经检查的异常的帮助都会有所帮助。

【问题讨论】:

    标签: java project-reactor


    【解决方案1】:

    没有明智的方法为这三个类创建一个通用接口。 (你可以,但返回类型必须是 Object,这可能不会让它太有用。)在“真实世界”服务中也是如此 - SqsClientSqsAsyncClient 只是阻塞/ 同一服务的非阻塞客户端,但没有一个“操作”方法定义来自公共接口。

    如果您真的必须拥有所有可用的选项,并且您将来可能会添加其他选项,那么这里最明智的做法可能是使用以下方式实现 actual 服务CompleteableFuture 然后使用该服务实现其他服务。这可能会为您提供最兼容的选项:

    class BlockingProfileService {
    
        CompletableFutureProfileService service;
    
        public BlockingProfileService(CompletableFutureProfileService service) {
            this.service = service;
        }
    
        Profile getProfile(String accessToken) {
            return service.getProfile(accessToken).get();
        }
    
        //..etc..
    

    和:

    class ReactorProfileService {
    
        CompletableFutureProfileService service;
    
        public ReactorProfileService(CompletableFutureProfileService service) {
            this.service = service;
        }
    
        Mono<Profile> getProfile(String accessToken) {
            return Mono.fromFuture(service.getProfile(accessToken));
        }
    

    您当然可以使用一些其他样板,这样您就不需要直接传入CompleteableFutureProfileService,可以在其他服务中使用必要的参数创建。

    但是,我担心您在这里可能会使事情过于复杂。如果您只是在整个过程中使用 reactor(这意味着 reactor 必须已经是一个依赖项),那么只需坚持使用 Mono - 无需混合使用 MonoCompletableFuture,当然也无需维护遗留阻塞API(因为可以通过阻塞任何异步库轻松获得。)

    【讨论】:

    • 感谢迈克尔的回复和澄清。我们的最终目标是退出阻塞实现,但我们还没有实现。目标是使用您上面建议的新反应式 API 来实现同步 API。不幸的是,到目前为止,我们无法触及当前的 API。由于 API 是库的一部分,并不是每个人都会有反应器,因此我们也需要支持原生 CompletableFutures。
    猜你喜欢
    • 1970-01-01
    • 2012-08-24
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-09-06
    • 2011-01-17
    相关资源
    最近更新 更多