Guice @Fournit des Méthodes vs Fournisseur de Classes

Je travaille sur un gros projet qui a beaucoup d'injections. Nous sommes actuellement à l'aide d'une classe qui implémente Provider pour chaque injection qui en a besoin, et ils ont surtout une ligne get méthodes.

Ça commence à devenir agaçant pour créer une nouvelle classe à chaque fois que j'ai besoin d'un nouveau fournisseur. Est-il un avantage à utiliser le fournisseur de cours @Provides méthodes dans mon Module ou l'inverse?

InformationsquelleAutor Eliezer | 2015-01-28
  1. 19

    Autant que je sache, ils sont exactement équivalentes pour la plupart des cas simples.

    /**
 * Class-style provider.
 * In module: bind(Foo.class).annotatedWith(Quux.class).toProvider(MyProvider.class);
 */
class MyProvider implements Provider<Foo> {
  @Inject Dep dep;  //All sorts of injection work, including constructor injection.

  @Override public Foo get() {
    return dep.provisionFoo("bar", "baz");
  }
}

/**
 * Method-style provider. configure() can be empty, but doesn't have to be.
 */
class MyModule extends AbstractModule {
  /** Name doesn't matter. Dep is injected automatically. */
  @Provides @Quux public Foo createFoo(Dep dep) {
    return dep.provisionFoo("bar", "baz");
  }

  @Override public void configure() { /* nothing needed in here */ }
}

    Dans le style, Guice vous permet d'injecter Foo et Provider<Foo>, même si la clé est lié à une classe ou une instance. Guice automatiquement les appels get si l'obtention d'une instance directement et crée un implicite Provider<Foo> si l'un n'existe pas. La liaison des annotations de travail dans les deux styles.

    Le principal avantage de @Fournit est la compacité, surtout en comparaison avec anonyme intérieure Fournisseur implémentations. Notez, cependant, qu'il pourrait y avoir quelques cas où vous souhaiteriez faveur des classes de Fournisseur:

    • Vous pouvez créer votre propre longue durée de vie des instances de Fournisseur, avec éventuellement des paramètres du constructeur, et de lier les clés de ces instances au lieu de la classe de littéraux.

      bind(Foo.class).toProvider(new FooProvisioner("bar", "baz"));

    • Si vous utilisez un cadre compatible avec la JSR 330 (javax.injecter), vous pouvez facilement lier à javax.injecter.Fournisseur de classes ou des instances. com.google.injecter.Le fournisseur s'étend de l'interface.

      bind(Foo.class).toProvider(SomeProviderThatDoesntKnowAboutGuice.class);

    • Votre Fournisseur peut être assez complexe à intégrer, dans sa propre classe. Selon la façon dont vous structurez vos tests, il peut être plus facile pour tester votre Fournisseur de cette façon.

    • Les fournisseurs peuvent étendre les classes abstraites. Il ne peut pas être facile ou intuitive pour le faire, avec @Fournit des méthodes.

    • Vous pouvez lier plusieurs touches pour le même Fournisseur directement. Chaque @Fournit la méthode produit exactement une liaison, mais on pouvait se lier à d'autres touches de la clé (@Quux Foo ici) et laissez Guice faire une seconde recherche.

    • Fournisseurs sont faciles à décorer ou de la pellicule, si vous voulez (par exemple) cache ou memoize des cas, sans l'aide de Guice étendues ou des liaisons.

      bind(Foo.class).toProvider(new Cache(new FooProvisioner("bar", "baz")));

    IMPORTANT: Si c'est une bonne stratégie pour les classes qui Guice ne pouvez pas créer, garder à l'esprit que Guice peut automatiquement créer et de les injecter un Provider<T> pour tout T que vous bind en aucune façon, y compris à un nom de classe, d'une clé ou d'une instance. Pas besoin de créer explicitement un fournisseur, sauf si il est logique réelle de votre propre cause.

    InformationsquelleAutor Jeff Bowman supports Monica
  2. 0

    Il y a aussi une différence dans la façon dont les classes sont instanciés.
    Pour Exemple : 

    public class GumProvider implements Provider<Gum> {

  public Gum get() {
    return new Gum();
  }
}
    public class GumModule extends AbstractModule {

    protected void configure() {

        bind(Gum.class).toProvider(GumProvider.class);
        //bind(Gum.class).to(GumballMachine.class);
    }
}
    public class GumballMachine {

    @Inject
    private Provider<Gum> gumProvider;

    Gum gum;


    public Gum dispense() {
        return gumProvider.get();
    }
}
    public class App {

    public static void main(String[] args) {
      //TODO Auto-generated method stub
      Injector injector = Guice.createInjector(new GumModule());
      GumballMachine m = injector.getInstance(GumballMachine.class);
      System.out.println(m.dispense());
      System.out.println(m.dispense());


    }

}

    Cela permettrait de créer une Instance de la Gomme Par l'Invocation.
    Alors que si @Fournit ont été utilisés de la même Instance de la Gomme serait passé à la fois les Injecteurs

    InformationsquelleAutor Jamie J