不得不处理 Guice，我想知道我应该如何处理模块方面的依赖关系。
在 Guice 中，每个模块都由一个实例提供。因此，如果我有一个需要某个服务的模块，它会创建该模块并添加一个绑定到该服务并安装它 (binder.install(module))。
现在我有两个独立的模块，它们完全可以独立使用，并且都安装了相同的数据库模块。
独立使用两个模块没有问题，但如果两个模块在同一个应用程序中使用会发生什么？数据库模块将由两个模块独立加载，这是不正确的。
有没有办法询问绑定器某个类型是否已经绑定？我无法使用 getProvider 进行检查，因为返回的所有内容都是 LookupProvider，无论某些内容是否已绑定。
那么如何处理这种情况呢？
更新：
它接缝 Guice 无法提供以下功能：
【问题讨论】：
Guice 有两个功能可以处理这种情况。第一个是模块重复数据删除。这意味着如果安装了两个等效的模块（通过equals() 和hashCode()），则只有一个configure() 方法将运行。但是，此解决方案有些脆弱，因为它无法通过 SPI 转换、Modules.override() 等。
第二个也是 IMO 更好的解决方案是绑定重复数据删除。这意味着 Guice 将接受完全重复的绑定。因此，如果您的模块执行bind(Interface.class).to(Implementation.class)，它的configure() 方法是否运行两次都没有关系，因为Guice 会很好地处理重复绑定。
【讨论】：
由于 Guice 不支持某些需要的功能，因此必须对其进行仿真。 multibinder 代码提供了一种思路。我目前使用的另一个想法是在注入器构建过程中使用反射来找到最顶层的绑定器。了解此活页夹后，您可以轻松添加所需的元信息并跟踪某些对象。
一旦构建过程完成，这些元信息将被删除。
通常一个人一次只构建一个注入器，但要确保我们应该防止这种情况发生。
所以看一下最单一的Binder实现（RecordingBinder）。它提供了一个字段 parent，我们可以走到根 binder 元素。通常 Guice 会使用一个最单一的 binder，但在私有模块的情况下。
另一个不那么安全但没有反射的想法是使用本地线程，如果您可以确保一次只构建一个 Guice 注入器。
能够识别构建过程并一次跟踪使用了哪些构建器，可以将任何类型的附加逻辑添加到 guice 中，例如防止安装依赖项两次。
【讨论】：
绑定重复数据删除似乎已在 Guice 4.0 中添加
https://github.com/google/guice/commit/c34e0185fcf508a890c6cd13bdafeb505c3e9e8a
【讨论】：