您现有的实现是最好的。
为了清楚起见，让我们写出一个 通用的 IPaymentFactory：
public interface IPaymentFactory { IPayment create();}因此，IPaymentFactory的实例定义了一个方法，该方法接受一些参数并返回IPayment的实例。您可以自己编写一个实现，当然也可以编写一个实现，但是Guice的FactoryModuleBuilder自动提供了这样的接口实现。您无需定义有关该类的任何其他内容：Guice将为您连接构造函数，并将其绑定到IPaymentFactory，以便您可以注入IPaymentFactory实例，
create(...)使用参数进行调用并获取IPayment实例。
看起来您要寻找的是一个需要枚举的工厂：
public interface IPaymentFactory { IPayment create(PaymentType paymentType);}......但鉴于CashPayment接受一个任意参数，并CardPayment需要两个任意参数，并给予它们之间的选择需要映射到任意PaymentType枚举，你没有给吉斯
几乎 足够的信息来构建合适的对象。
Guice FactoryModuleBuilder设计用于结合构造函数参数和依赖项：
// Constructor:@Inject public BitcoinPayment( @Assisted long value, // varies by instance as a constructor parameter BitcoinService bitcoinService // passed-in dependency satisfied by Guice ) { }// Factory interface:public IBitcoinPaymentFactory { BitcoinPayment create(long value); // users don't need to know about dependencies!}// Factory binding...install(new FactoryModuleBuilder().build(IBitcoinPaymentFactory.class));// ...which lets Guice write the equivalent of:public GeneratedBitcoinPaymentFactory implements IBitcoinPaymentFactory { @Inject Provider<BitcoinService> bitcoinServiceProvider; @Override public BitcoinPayment create(long value) { return new BitcoinPayment(value, bitcoinServiceProvider.get()); }}一方面，工厂比您想象的要笨：它只是将参数与依赖项结合在一起，以获得一个完整的列表。另一方面，它很方便：只需指定一次依赖项列表，剩下的就由Guice完成。
总结：
FactoryModuleBuilder不会解决您的问题，但是它可以帮助您为CashPayment和CardPayment创建工厂，然后将它们注入到您的手动PaymentFactory实现中（它们仍然需要以某种形式存在）。
PS在您的示例中，这可能是演示的“玩具问题”，您可能不需要使用Guice。对于需要依赖关系的服务对象，Guice是一个很好的解决方案，但是可以直接使用构造函数来构造数据对象（例如付款）或其他不需要依赖关系的对象（例如GuiceService或NaiveService）。一旦他们开始需要Guice注入的依赖关系，就很容易使他们了解Guice。
