¿Inyectar Util Class con Google Guice vs static Methods?

Question

Me pregunto si es un buen estilo para inyectar métodos de utilidad con google guice.

Digamos que tenemos una utilidad de la clase Convertidor:

public class UtilClass 
{ 
    public static Result convert(Source src) 
    { 
    //Do conversion 

    return result; 
    } 
} 

Mi idea es utilizar guice para inyectar esta utilidad como Singleton como esto

@Singleton 
public class UtilClass 
{ 
    public Result convert(Source src) 
    { 
    //Do conversion 

    return result; 
    } 
} 

Por qué camino se recomienda para una aplicación creada con Guice?

Answer 1

Depende de la naturaleza de su método convert().

Si es algo

• sencilla
• determinista (es decir, no depende de parámetros adicionales)
• no tienen efectos secundarios
• es poco probable que cambie
• etc

puede mantenerlo como un método de utilidad estático.

De lo contrario, es un buen candidato para la inyección de dependencia (puede cambiar el nombre a ConversionService para hacerlo más claro).

Answer 2

En primer lugar, ¿cuál es su objetivo al inyectar una instancia de esta clase de utilidad en lugar de seguir utilizando el método estático que tiene? Las funciones con entrada y salida y sin efectos secundarios a menudo son mejores como métodos estáticos. Dicho esto, tal vez quieras poder cambiar lo que este método hace para probar o algo así. En ese caso, generalmente desea que la clase implemente alguna interfaz que use en clases de clientes.

En cualquier caso, si UtilClass es apátrida, solo lo inyectaría no como singleton. Inyectar un no singleton es más rápido que inyectar un singleton. Tal vez si va a almacenar la instancia inyectada en muchas otras clases, un singleton podría tener sentido para ahorrar espacio.

Answer 3

Personalmente, por lo general trato de no permitir que mi aplicación se conecte usando un marco de inyección de dependencia, influyo en las decisiones de diseño que tomo para mis clases, etc. Las buenas prácticas de diseño deberían dictar eso. En su caso, parecería que su clase de utilidad no tiene dependencia del estado, por lo tanto, parece un candidato razonable para permanecer como estático.

Independientemente de esto, su clase de utilidad no es una implementación de ninguna interfaz, por lo que el código del cliente que la utiliza tiene una estrecha dependencia. Con esto, es difícil ver cuál es la ventaja de usar DI para inyectar la clase de utilidad en absoluto, en lugar de solo hacer referencia a la clase estática directamente en su código de cliente.