我正在为 Web API 构建客户端 SDK，并尝试通过 guice 应用依赖注入(inject)。这个 Java 客户端将被第三方用作访问我们的 API 的一种方式。

我希望能够注入(inject)我的外部依赖项(使用的 HTTP 客户端等)，并为开发人员提供一种方法来注入(inject)这些依赖项的不同版本，如果他们愿意或者如果我想自己更改实现(一个很好的依赖注入(inject)的案例对吗？)。

然而，为了连接依赖关系，我必须让我的库的用户创建一个注入(inject)器等。像这样:

Injector injector = Guice.createInjector(new MyAPIClientModule(url, username, password));
        this.service = injector.getInstance(MyAPIService.class);

我不想将它推送给我的库的用户，但我仍然想让用户能够选择不同的实现或底层 HTTP 库等。

我是否在这里以某种方式错过了 guice 或 DI 的要点？这是使用 guice 时的标准做法吗？

或者我应该将它包装在另一个执行注入(inject)的类中，并只向第三方用户提供一个示例 Java 对象吗？

最佳答案

I want to be able to inject my external dependencies(The http client used etc.) and give a way for developers to inject different versions of those dependencies if they wanted or if I ever wanted to change the implementation myself(a good case for dependency injection right?).

这对于 DI 来说是一个很好的案例，这是很有争议的。像 HTTP 客户端这样的外部依赖项通常有具体的接口(interface)，除了那个依赖项之外没有人实现。就我个人而言，我无法想象您的程序是如何编写的，因为交换底层 HTTP 客户端不会影响其架构，也就是说，除非您为其提供您自己的外观，像

public interface HttpClient {
    HttpResponse send(HttpRequest request);
}

其中 HttpRequest 和 HttpResponse 也是自定义类/接口(interface)。但是向最终用户提供这种扩展点很少是合适的，特别是如果你没有一些引用实现(这意味着用户将不得不为他/她的依赖创建这个外观想要)。它在极少数情况下是合适的，但很可能这不是您的情况。

相同依赖项的不同版本通常也不是 DI 的情况，因为交换版本可以在构建/组装时完成。

如果您希望向用户展示一种能力，让他们能够为您的某些库“移动部件”提供他们自己的实现，那么首先您必须为所有这些移动部件定义严格的接口(interface)。换句话说，提供一组 interface，您的用户必须扩展这些接口(interface)并将其注入(inject)到您的类中。

然后创建由 Guice 模块组成的“绑定(bind)空间”，并在这些模块中声明对这些接口(interface)的要求:

public class SomeModule extends AbstractModule {
    @Override
    protected void configure() {
        requireBinding(SomeUserAPI.class);
        // Other bindings which probably use SomeUserAPI in implementations
    }
}

通过声明必需的绑定(bind)，您可以确保没有人能够混入您的模块，除非他们提供给定类的某些实现。当然，如果找不到绑定(bind)，Guice 无论如何都会失败，但是当您明确要求它时，您会获得更具体的错误消息，以及清晰的模块接口(interface)。

然后您为您的库创建特殊的“入口点”，其唯一职责是创建注入(inject)器并为用户提供您的类的实例。该类接受用户的 Guice 模块并将其集成到注入(inject)器中。

public class Library {
    private final Injector injector;

    private Library(Module userModule) {
        // SomeModule and AnotherModule are modules defined in the library
        // and they are not the part of public interface of your library
        this.injector = Guice.createInjector(userModule, new SomeModule(), new AnotherModule());
    }

    public static Library create(Module userModule) {
        return new Library(userModule);
    }

    public MyAPIService myAPIService() {
        return injector.getInstance(MyAPIService.class);
    }
}

然后用户这样使用它:

Library library = Library.create(new AbstractModule() {
    @Override
    protected void configure() {
        // recall requireBinding(SomeUserAPI.class) statement we wrote previously,
        // here we are "implementing" it
        bind(SomeUserAPI.class).to(SomeUserAPIImpl.class);
        // other bindings for your exposed interfaces
    }
});
MyAPIService service = library.myAPIService();

在这种方法中，您允许用户以一种简洁且可控的方式使用 Guice DI 扩展您的库。

但是，您仍然必须向用户公开 Guice(因为用户必须实现 Module 接口(interface))。我不认为你可以完全避免这种情况，除非你做一些奇怪的事情，比如

Library.create(SomeUserAPIImpl.class, SomeUserAPI2Impl.class, ...)

也就是说，接受表示扩展点实现的类对象(然后将它们绑定(bind)到某个内部模块中)。但我认为从库界面中删除 Guice 并不值得。

关于java - 使用 guice 为客户端 sdk/library 设计模式进行依赖注入(inject)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22184736/