2009-02-27 15 views
8

Acabo de heredar una aplicación Java y al inspeccionar el código, veo lo que en mi humilde opinión es una bastardización del framework Spring. Usted ve, el equipo de Java parece tener una aversión a las interfaces, por lo que termina con cosas como esta:Primavera como una fábrica glorificada; es esto aceptable?

@Autowired 
private SomeConcreteFinalClass _myField; 

No hay ninguna configuración de la primavera, sin frijol definido, no hay posibilidad de que puedo probar el objeto que contiene de manera aislada . Esto es esencialmente una fábrica basada en anotaciones con los gastos generales de Spring.

¿Estoy fuera de línea, o es como usar una pistola de elefantes para matar moscas? Solo tengo que comprobar la realidad desde , todos los demás en el equipo piensan que esto es perfectamente aceptable.

Editar En muchos casos, estas fábricas anotadas aparecen en clases de procesamiento complejas que se beneficiarían inmensamente de las pruebas aisladas. El equipo también frunce el ceño ante las pruebas.

No hay misterio aquí, espero. Si tengo una clase concreta, eso no está detrás de una interfaz, y no hay un Spring Bean correspondiente para "configurar" el objeto, entonces es indiscutiblemente una fábrica glorificada que puede implementarse con 10 líneas de código.

El resorte no se usa de ninguna otra forma en el sistema; eso es todo.

Mis objetivos ahora mismo:

  • instituir una política de pruebas
  • Educar el equipo sobre las virtudes del componente aislamiento
  • mover estos campos Autowired detrás de las interfaces

I Supongo que la última pregunta es: ¿hay algún beneficio para mantener estos campos Autocableados si no estamos probando g o de cualquier otra manera utilizando el marco. Igualmente me gustaría new el objeto si la dependencia es inmutable.

+0

Por supuesto: un arma de elefante es el arma de elección para matar moscas mutantes del tamaño de un elefante –

Respuesta

4

Estoy de acuerdo con usted en que esto es un abuso de lo que Spring puede hacer (en comparación con lo que Spring DEBE hacer). ¿Es la persona que diseñó la aplicación de esta manera? Sería interesante escuchar su justificación para construir una aplicación de esta manera.

1

No puedo decir que veo el punto por completo. Después de todo, es probable que haya unas pocas líneas de código para conectar el sistema en un método main y no tendrá la dependencia de Spring.

Y sí, estoy de acuerdo en que no inyectar interfaces es un poco inútil. Tiendo a no hacer una gran cantidad de pruebas de Unidad pero, aún así, perdería flexibilidad en el cambio de implementaciones más adelante (o tener diferentes implementaciones de clases en diferentes implementaciones, por ejemplo, pruebas de integración).

4

Sin duda es una limitación de lo que es posible, pero tampoco es una pérdida de tiempo total.

Dado que el tipo en cuestión es final, no se puede burlar fácilmente para pruebas aisladas.

Sin embargo, las instancias de ese tipo aún pueden ser altamente configurables a través de sus propiedades.Usar Spring para inyectar una instancia que está configurada correctamente en el tiempo de ejecución simplifica enormemente la clase contenedora. La clase puede enfocarse en sus responsabilidades, confiando en Spring para proporcionarle los colaboradores que necesita.

Las interfaces son más usadas; esto puede ser una respuesta a eso. Creo que comenzar con clases finales y concretas para muchos tipos, y luego usar herramientas de refactorización fácilmente disponibles para extraer interfaces más adelante, cuando se identifica una necesidad específica, es una posición defendible en muchos contextos.

+0

Si el tipo es definitivo, podría haber una interfaz para el aislamiento de la extensibilidad y la capacidad de prueba. En muchos casos, estas fábricas anotadas aparecen en clases de procesamiento complejas que se beneficiarían inmensamente de las pruebas aisladas. También fruncen el ceño al momento de las pruebas. –

+0

+1 para un argumento de contador razonable. –

+0

"Fruncir el ceño en las pruebas", ¿eh? ¡Me temo que no puedo hablar en su defensa allí! ;) – erickson

1

Lo siento, pero no puedo decir si esto es un abuso de Spring basado en las dos líneas de código que ha publicado y dudo que alguien más pueda, tampoco.

Si se queja del hecho de que el tipo estático de ese objeto no es una interfaz, es posible que tenga sentido. Pero incluso eso es difícil de decir desde esa única línea de código. ¿Es realmente una clase de servicio o repositorio sin interfaz? Si es así, estoy de acuerdo. Si no, necesitaría saber más.

Si tu equipo frunce el ceño en las pruebas, es una lástima. Hubiera pensado que uno de los motivos de Spring sería facilitar las pruebas.

Puede que tenga un punto, pero no puedo estar seguro de su pregunta original. Tal vez puedas editar con más detalle.

Si este es un ejemplo de cómo te comunicas con tus compañeros de equipo, quizás estarían justificados si dijeran que no te explicaste muy bien. Asegúrate de no estar solo aquí para tu propio engrandecimiento.

+0

Gracias por su comentario. En general, proporciono detalles suficientes para que los expertos en el área puedan juntarlo o pedir más detalles. El golpe en mis habilidades de comunicación fue un poco fuera de lugar, pero +1 para resaltar la necesidad de más detalles. –

+1

"Generalmente proporciono suficientes detalles", no esta vez. Y solo tus compañeros de equipo pueden darte comentarios significativos sobre si tus habilidades de comunicación son suficientes. Preocúpate menos por lo que pienso y más acerca de ellos. Sugeriría que consideres obtenerlo en lugar de asumir que están equivocados. – duffymo

Cuestiones relacionadas