¡Ver pregunta en el título! ¿'Inyectarías' o mejor dicho 'nuevo' un Comparador? ¿Sería nuevo si el orden de los elementos se establece en la especificación y es probable que no cambie?¿Los comparadores son objetos nuevos o inyectables?
La pregunta "¿Debería inyectar esta dependencia?" es realmente "¿debería saber el objeto referente sobre la naturaleza de esta dependencia?". Er, solo negado.
Si su clase es FastestPonyFinder, y necesita ordenar un List<Pony> por velocidad, entonces yo diría que debería saber sobre el comparador. El comparador necesita comparar por velocidad, clasificando el más rápido al encabezado de la lista; ningún otro comparador es adecuado para el trabajo. El objeto debe crear el comparador, tal como creó el List.
Si su clase es BestPonyFinder, entonces probablemente debería tener el comparador inyectado, porque la definición de lo que constituye 'mejor' es separable de la definición de cómo encontrar el poni que lo satisface. Esto hará que su código sea más fácil de probar y más fácil de cambiar en el futuro.
¡Gracias por la respuesta! Siguiendo esta línea de pensamiento, ¿podrías entonces convertir "nuevo" un TodaysPoniesFinder en un FastestPonyFinder cuando sabes que tu aplicación siempre funcionará en las carreras de caballos en un día específico? ¿O elegiría lo contrario, teniendo en cuenta que TodaysPoniesFinder es probablemente algo más complejo que un Comparador? (Por favor, ignore el hecho de que probablemente no haría algo así como un "TodaysPoniesFinder" teniendo en cuenta los problemas de testabilidad de las fechas :)). ¡Gracias! – user1405469
Si el trabajo de 'TodaysPoniesFinder' es hacer una lista de todos los potros que compiten hoy, entonces diría que' FastestPonyFinder' no necesita saber lo que está haciendo; solo le importa que produzca una lista de ponies. Por lo tanto, debe ser inyectado. Probablemente debería inyectarse como un parámetro de algún tipo, como 'PonyFinder', en lugar del tipo concreto. –
Como un lado, 'TodaysPoniesFinder' sería perfectamente comprobable, ¡siempre y cuando inyecte el valor de 'hoy' en él! Este es un [movimiento clásico en TDD simulado] (http://www.mockobjects.com/2007/04/test-smell-i-need-to-mock-object-i-cant.html); por lo general, escribe una clase de reloj muy simple {public Date now() {return new Date(); }} 'e inyecte eso en cualquier objeto que necesite saber la hora. A continuación, puede inyectar un simulacro en lugar de prueba. –
Lo que ocurre con los comparadores es que son baratos. No suelen tener campos, y si lo hacen, no tienen muchos.
Son tan baratos que en realidad no importa. Puede construirlos en línea, o obtenerlos de un campo final estático, o recibir una inyección única: ¿a quién le importa?
Desde la perspectiva de las pruebas unitarias, básicamente dice que los Comparadores son baratos, al igual que los métodos getter/setter, ¿no? Entonces, no consideraría escribir pruebas para ellos ... – user1405469
Depende. Ciertamente probaría los métodos que los usan. –
Además, si no hay un estado, siempre puede "reutilizar". En este caso, son seguros para subprocesos y no entran en un estado de un uso anterior. Entonces, al final, realmente depende de cómo implemente el comparador: con estado o sin él.
Para la prueba de la unidad es mejor tener una nueva instancia de Comparator, pero no importa si su comparador acaba de implementar el método de comparación. Si desea inyectar algunos datos como estado para el comparador y el uso modificable, utilice los métodos de prueba Antes y Después para asegurarse de no utilizar el contexto anterior.
¡Buena pregunta! Las respuestas revelan una amplia gama de ideas sobre qué inyección es fundamentalmente * para *. –