27
Digamos que tengo una clase de utilidad DateUtil (ver a continuación). Para utilizar este método , un método de llamada utiliza DateUtils.getDateAsString (aDate). ¿Sería mejor eliminar el modificador estático y hacer que DateUtil sea un bean de primavera (ver DateUtilsBean) e inyectarlo en las clases llamantes o simplemente dejarlo como está?Clase de utilidad en la aplicación Spring: ¿debo usar métodos estáticos o no?
Una desventaja que puedo ver con el uso de estática es cuestiones en torno de burla, ver How to mock with static methods?
public class DateUtils {
public static String getDateAsString(Date date) {
String retValue = "" // do something here using date parameter
return retValue;
}
}
de beans Spring versión
@Component
public class DateUtilsBean {
public String getDateAsString(Date date) {
String retValue = "" // do something here using date parameter
return retValue;
}
}
De acuerdo. El hecho de que "cualquier cosa" pueda ser cableado como un bean de primavera no significa todo lo que debería estar conectado como un bean de primavera. –
¿Qué sucede si el método estático lee un archivo de configuración que maneja mi aplicación? es probable que quiera burlarme de ese comportamiento. Solo piense en eso: quiere hacer pruebas funcionales pero no quiere convertirse en una "fábrica de configuración". si fuera un singleton, entonces puedo burlarme más fácilmente de ese método y sacar mi prueba del código. Sin embargo, es posible con PowerMock simular también métodos estáticos. – uthomas
Podría ser una sobreingeniería, pero convertirla en un frijol que se puede inyectar hace que resulte más fácil probar las clases dependientes. Sería aún más fácil probar si se hubiera implementado una interfaz. – Behrang