2009-06-24 8 views
7

acabo de retocar con Google Guice para Dependency Injection y comencé a integrarlo en mi aplicación existente. Hasta aquí todo bien. Tengo muchas clases que necesitan, además de sus dependencias, Strings, DataSources, etcétera. Sé que hay NamedBindings, pero realmente no quiero crear una anotación para cada cadena simple que tengo que pasar al constructor para cada clase. Luego, hay una cosa llamada AssistedInject, que crea Implementaciones de fábrica para mí. Guau, pero aún tengo que definir la interfaz de la fábrica. Eso está bien para las clases que sí tienen dependencias, pero qué pasa con esta clase de ejemplo:Inyección de Dependencia con Guice: algo que no está cubierto por ningún tutorial

public class FooBarClass { 
    public FooBarClass(String name, String anotherOne) { 
     // Some stuff 
    } 
} 

Hay casos en los que estoy en duda cómo utilizar Guice o, más generalmente, DI de la manera correcta. "A menudo oigo: XYZ Framework es el nuevo nuevo". Pero esto implícito que tengo que crear cada instancia con el marco DI.

Sólo se requiere una instancia

¿Y si necesito sólo una instancia de esta clase? Esta clase no tiene absolutamente ninguna dependencia al lado de dos cadenas. Piensa en un Shutdown Hook que se instanciará solo una vez y se pasará a la JVM como mi Shutdown Hook. ¿Debo crear esta instancia con Guice? Esto me parece muy tonto, porque no hay nada que inyectar, pero tengo que escribir una interfaz de fábrica para pasar los dos parámetros a Guide y tengo que crear una interfaz para que mi FooBarClass use DI.

casos se requieren múltiples

Lo mismo se aplica a un caso en el que necesito varias instancias de esta clase. No hay dependencias, pero tengo que crear un montón de código repetitivo para obtener nada de eso. Esto me parece mal.

Entonces, ¿cómo se supone que debo usar DI y/o Guice?

¡Muchas gracias!

Respuesta

23

Podría ayudar a dividir dependencias de datos.

  • Las dependencias a menudo son servicios: bases de datos, relojes y resguardos RPC. Además de todo el código de la aplicación en capas en estos: UserAuthenticator, PaymentHandler y EmailGateway.
  • Datos son solo eso: un Date, un Map<String,InetAddress> o incluso un Customer. Estos son objetos de dominio simples en memoria.

DI es, naturalmente, el más adecuado para el lado de la dependencia de las cosas. Debe seguir utilizando new para sus clases de modelo de datos.

2

si está creando varias instancias, como clientes individuales, no tiene sentido inyectarlas. lo que tiene sentido es crear una CustomerFactory que puede ser el alcance @Singleton que puede crear instancias de Cliente con todas sus dependencias.

2

Inyecte una dependencia si desea ignorar (aislar) su complejidad al probar una clase en particular. Si la clase es solo un titular de datos, su código es trivial (get, set, equals). No es necesario que se burle de él cuando prueba la clase objetivo, por lo que inyectar la instancia de datos es excesivo (y generalmente difícil).Si el código no es trivial, la clase es más que un titular de datos, y debe inyectarla y simularla en pruebas unitarias.

Cuestiones relacionadas