* bind(ServiceImpl.class);* * This statement does essentially nothing; it "binds the {@code ServiceImpl} * class to itself" and does not change Guice's default behavior. You may still * want to use this if you prefer your {@link Module} class to serve as an * explicit manifest for the services it provides. Also, in rare cases, * Guice may be unable to validate a binding at injector creation time unless it * is given explicitly. * *
* bind(Service.class).to(ServiceImpl.class);* * Specifies that a request for a {@code Service} instance with no binding * annotations should be treated as if it were a request for a * {@code ServiceImpl} instance. This overrides the function of any * {@link ImplementedBy @ImplementedBy} or {@link ProvidedBy @ProvidedBy} * annotations found on {@code Service}, since Guice will have already * "moved on" to {@code ServiceImpl} before it reaches the point when it starts * looking for these annotations. * *
* bind(Service.class).toProvider(ServiceProvider.class);* * In this example, {@code ServiceProvider} must extend or implement * {@code Provider
The {@link Provider} you use here does not have to be a "factory"; that * is, a provider which always creates each instance it provides. * However, this is generally a good practice to follow. You can then use * Guice's concept of {@link Scope scopes} to guide when creation should happen * -- "letting Guice work for you". * *
* bind(Service.class).annotatedWith(Red.class).to(ServiceImpl.class);* * Like the previous example, but only applies to injection requests that use * the binding annotation {@code @Red}. If your module also includes bindings * for particular values of the {@code @Red} annotation (see below), * then this binding will serve as a "catch-all" for any values of {@code @Red} * that have no exact match in the bindings. * *
* bind(ServiceImpl.class).in(Singleton.class); * // or, alternatively * bind(ServiceImpl.class).in(Scopes.SINGLETON);* * Either of these statements places the {@code ServiceImpl} class into * singleton scope. Guice will create only one instance of {@code ServiceImpl} * and will reuse it for all injection requests of this type. Note that it is * still possible to bind another instance of {@code ServiceImpl} if the second * binding is qualified by an annotation as in the previous example. Guice is * not overly concerned with preventing you from creating multiple * instances of your "singletons", only with enabling your application to * share only one instance if that's all you tell Guice you need. * *
Note: a scope specified in this way overrides any scope that * was specified with an annotation on the {@code ServiceImpl} class. * *
Besides {@link Singleton}/{@link Scopes#SINGLETON}, there are * servlet-specific scopes available in * {@code com.google.inject.servlet.ServletScopes}, and your Modules can * contribute their own custom scopes for use here as well. * *
* bind(new TypeLiteral<PaymentService<CreditCard>>() {})
* .to(CreditCardPaymentService.class);
*
* This admittedly odd construct is the way to bind a parameterized type. It
* tells Guice how to honor an injection request for an element of type
* {@code PaymentService* bind(Service.class).toInstance(new ServiceImpl()); * // or, alternatively * bind(Service.class).toInstance(SomeLegacyRegistry.getService());* * In this example, your module itself, not Guice, takes responsibility * for obtaining a {@code ServiceImpl} instance, then asks Guice to always use * this single instance to fulfill all {@code Service} injection requests. When * the {@link Injector} is created, it will automatically perform field * and method injection for this instance, but any injectable constructor on * {@code ServiceImpl} is simply ignored. Note that using this approach results * in "eager loading" behavior that you can't control. * *
* bindConstant().annotatedWith(ServerHost.class).to(args[0]);* * Sets up a constant binding. Constant injections must always be annotated. * When a constant binding's value is a string, it is eligile for conversion to * all primitive types, to {@link Enum#valueOf(Class, String) all enums}, and to * {@link Class#forName class literals}. Conversions for other types can be * configured using {@link #convertToTypes(Matcher, TypeConverter) * convertToTypes()}. * *
* {@literal @}Color("red") Color red; // A member variable (field)
* . . .
* red = MyModule.class.getDeclaredField("red").getAnnotation(Color.class);
* bind(Service.class).annotatedWith(red).to(RedService.class);
*
* If your binding annotation has parameters you can apply different bindings to
* different specific values of your annotation. Getting your hands on the
* right instance of the annotation is a bit of a pain -- one approach, shown
* above, is to apply a prototype annotation to a field in your module class, so
* that you can read this annotation instance and give it to Guice.
*
*
* bind(Service.class)
* .annotatedWith(Names.named("blue"))
* .to(BlueService.class);
*
* Differentiating by names is a common enough use case that we provided a
* standard annotation, {@link com.google.inject.name.Named @Named}. Because of
* Guice's library support, binding by name is quite easier than in the
* arbitrary binding annotation case we just saw. However, remember that these
* names will live in a single flat namespace with all the other names used in
* your application.
*
* * Constructor* * In this example, we directly tell Guice which constructor to use in a concrete * class implementation. It means that we do not need to place {@literal @}Inject * on any of the constructors and that Guice treats the provided constructor as though * it were annotated so. It is useful for cases where you cannot modify existing * classes and is a bit simpler than using a {@link Provider}. * *loneCtor = getLoneCtorFromServiceImplViaReflection(); * bind(ServiceImpl.class) * .toConstructor(loneCtor);
The above list of examples is far from exhaustive. If you can think of * how the concepts of one example might coexist with the concepts from another, * you can most likely weave the two together. If the two concepts make no * sense with each other, you most likely won't be able to do it. In a few * cases Guice will let something bogus slip by, and will then inform you of * the problems at runtime, as soon as you try to create your Injector. * *
The other methods of Binder such as {@link #bindScope}, * {@link #bindInterceptor}, {@link #install}, {@link #requestStaticInjection}, * {@link #addError} and {@link #currentStage} are not part of the Binding EDSL; * you can learn how to use these in the usual way, from the method * documentation. * * @author crazybob@google.com (Bob Lee) * @author jessewilson@google.com (Jesse Wilson) * @author kevinb@google.com (Kevin Bourrillion) */ public interface Binder { /*if[AOP]*/ /** * Binds method interceptor[s] to methods matched by class and method matchers. A method is * eligible for interception if: * *
bind(Foo.class).to(FooImpl.class)) are allowed, but the
* implicit binding (FooImpl) cannot be directly injected unless
* it is also explicitly bound (bind(FooImpl.class)).
* * Tools can still retrieve bindings for implicit bindings (bindings created * through a linked binding) if explicit bindings are required, however * {@link Binding#getProvider} will fail. *
* By default, explicit bindings are not required. *
* If a parent injector requires explicit bindings, then all child injectors * (and private modules within that injector) also require explicit bindings. * If a parent does not require explicit bindings, a child injector or private * module may optionally declare itself as requiring explicit bindings. If it * does, the behavior is limited only to that child or any grandchildren. No * siblings of the child will require explicit bindings. *
* In the absence of an explicit binding for the target, linked bindings in * child injectors create a binding for the target in the parent. Since this * behavior can be surprising, it causes an error instead if explicit bindings * are required. To avoid this error, add an explicit binding for the target, * either in the child or the parent. * * @since 3.0 */ void requireExplicitBindings(); /** * Prevents Guice from constructing a {@link Proxy} when a circular dependency * is found. By default, circular proxies are not disabled. *
* If a parent injector disables circular proxies, then all child injectors * (and private modules within that injector) also disable circular proxies. * If a parent does not disable circular proxies, a child injector or private * module may optionally declare itself as disabling circular proxies. If it * does, the behavior is limited only to that child or any grandchildren. No * siblings of the child will disable circular proxies. * * @since 3.0 */ void disableCircularProxies(); /** * Requires that a {@literal @}{@link Inject} annotation exists on a constructor in order for * Guice to consider it an eligible injectable class. By default, Guice will inject classes that * have a no-args constructor if no {@literal @}{@link Inject} annotation exists on any * constructor. *
* If the class is bound using {@link LinkedBindingBuilder#toConstructor}, Guice will still inject
* that constructor regardless of annotations.
*
* @since 4.0
*/
void requireAtInjectOnConstructors();
/**
* Requires that Guice finds an exactly matching binding annotation. This disables the
* error-prone feature in Guice where it can substitute a binding for
* {@literal @}Named Foo when attempting to inject
* {@literal @}Named("foo") Foo.
*
* @since 4.0
*/
void requireExactBindingAnnotations();
/**
* Adds a scanner that will look in all installed modules for annotations the scanner can parse,
* and binds them like {@literal @}Provides methods. Scanners apply to all modules installed in
* the injector. Scanners installed in child injectors or private modules do not impact modules in
* siblings or parents, however scanners installed in parents do apply to all child injectors and
* private modules.
*
* @since 4.0
*/
void scanModulesForAnnotatedMethods(ModuleAnnotatedMethodScanner scanner);
}