¿Qué es exactamente Field Injection y cómo evitarlo?

Leí en algunas publicaciones sobre Spring MVC y Portlets que no se recomienda la inyección de campo . Según tengo entendido, la inyección de campo es cuando se inyecta un Bean @Autowiredasí:

@Component
public class MyComponent {
    @Autowired
    private Cart cart;
}

Durante mi investigación también leí sobre la inyección de constructores :

@Component
public class MyComponent {
    private final Cart cart;

    @Autowired
    public MyComponent(Cart cart){
       this.cart = cart;
    }
}

¿Cuáles son las ventajas y las desventajas de ambos tipos de inyecciones?

EDITAR 1: Como esta pregunta está marcada como un duplicado de esta pregunta, la revisé. Porque no hay ejemplos de código ni en la pregunta ni en las respuestas, no me queda claro si estoy en lo cierto con mi suposición de qué tipo de inyección estoy usando.

Tipos de inyecciones

Hay tres opciones para inyectar dependencias en un bean:

1. A través de un constructor
2. A través de setters u otros métodos
3. A través de la reflexión, directamente en los campos

Está utilizando la opción 3. Eso es lo que sucede cuando utiliza @Autowireddirectamente en su campo.

Pautas de inyección

Una pauta general recomendada por Spring (consulte las secciones sobre DI basada en Constructor o DI basada en Setter ) es la siguiente:

• Para dependencias obligatorias o cuando se apunta a la inmutabilidad, use la inyección del constructor
• Para dependencias opcionales o cambiables, use la inyección de setter
• Evite la inyección de campo en la mayoría de los casos

Inconvenientes de la inyección de campo

Las razones por las que la inyección de campo está mal vista son las siguientes:

• No puede crear objetos inmutables, como puede hacerlo con la inyección del constructor
• Sus clases tienen un acoplamiento estrecho con su contenedor DI y no se pueden usar fuera de él
• No se pueden crear instancias de sus clases (por ejemplo, en pruebas unitarias) sin reflexión. Necesita el contenedor DI para instanciarlos, lo que hace que sus pruebas se parezcan más a pruebas de integración
• Sus dependencias reales están ocultas desde el exterior y no se reflejan en su interfaz (ni constructores ni métodos)
• Es realmente fácil tener como diez dependencias. Si estuviera usando inyección de constructor, tendría un constructor con diez argumentos, lo que indicaría que algo está sospechoso. Pero puede agregar campos inyectados usando la inyección de campo indefinidamente. Tener demasiadas dependencias es una señal de alerta de que la clase generalmente hace más de una cosa y que puede violar el principio de responsabilidad única.

Conclusión

Dependiendo de sus necesidades, debe usar principalmente inyección de constructor o alguna combinación de inyección de constructor y setter. La inyección de campo tiene muchos inconvenientes y debe evitarse. La única ventaja de la inyección de campo es que es más conveniente escribir, lo que no supera todas las desventajas.

Otras lecturas

Escribí un artículo de blog sobre por qué la inyección de campo generalmente no se recomienda: Inyección de dependencia de campo considerada dañina .

Esta es una de las discusiones interminables en el desarrollo de software, pero las principales personas influyentes en la industria se están volviendo más obstinadas sobre el tema y comenzaron a sugerir la inyección de constructores como la mejor opción.

Inyección de constructor

Pros:

• Mejor capacidad de prueba . No necesita ninguna biblioteca burlona o un contexto Spring en las pruebas unitarias. Puede crear un objeto que desee probar con la nueva palabra clave. Estas pruebas son siempre más rápidas porque no dependen del mecanismo de reflexión. ( Esta pregunta se hizo 30 minutos después. Si el autor hubiera utilizado la inyección del constructor, no habría aparecido).
• Inmutabilidad . Una vez que se establecen las dependencias, no se pueden cambiar.
• Código más seguro . Después de la ejecución de un constructor, su objeto está listo para usar, ya que puede validar cualquier cosa que se haya pasado como parámetro. El objeto puede estar listo o no, no hay un estado intermedio. Con la inyección de campo se introduce un paso intermedio cuando el objeto es frágil.
• Expresión más limpia de dependencias obligatorias . La inyección de campo es ambigua en este asunto.
• Hace que los desarrolladores piensen en el diseño . dit escribió sobre un constructor con 8 parámetros, que en realidad es el signo de un mal diseño y el antipatrón del objeto Dios . No importa si una clase tiene 8 dependencias en su constructor o en campos, siempre es incorrecto. La gente es más reacia a agregar más dependencias a un constructor que a través de campos. Funciona como una señal para tu cerebro de que debes detenerte un rato y pensar en la estructura de tu código.

Contras:

• Más código (pero los IDE modernos alivian el dolor).

Básicamente, la inyección de campo es lo contrario.

Cuestion de gusto. Es tu decisión.

Pero puedo explicar por qué nunca uso la inyección del constructor .

1. No quiero poner en práctica un constructor para todos mis @Service, @Repositoryy @Controllerfrijoles. Quiero decir, hay alrededor de 40-50 frijoles o más. Cada vez que agrego un nuevo campo, tendría que extender el constructor. No. No lo quiero y no tengo que hacerlo.

2. ¿Qué pasa si su Bean (Servicio o Controlador) requiere que se inyecten muchos otros granos? Un constructor con 4+ parámetros es muy feo.

3. Si estoy usando CDI, el constructor no me concierne.

EDITAR # 1 : Vojtech Ruzicka dijo:

la clase tiene demasiadas dependencias y probablemente está violando el principio de responsabilidad única y debería refactorizarse

Si. Teoría y realidad. Aquí hay un ejemplo: DashboardControllermapeado a una ruta única *:8080/dashboard.

My DashboardControllerrecopila mucha información de otros servicios para mostrarla en una página de descripción general del panel / sistema. Necesito este único controlador. Así que tengo que asegurar solo esta ruta (autenticación básica o filtro de rol de usuario).

EDICIÓN # 2 : Dado que todos están enfocados en los 8 parámetros en el constructor ... Este fue un ejemplo del mundo real: un código heredado de un cliente. He cambiado eso. La misma argumentación se aplica a mí para más de 4 parámetros.

Se trata de inyección de código, no de construcción de instancias.

Un comentario más: Vojtech Ruzicka declaró que Spring inyecta frijoles de tres maneras (la respuesta con la mayor cantidad de puntos):

1. A través de un constructor
2. A través de setters u otros métodos
3. A través de la reflexión, directamente en los campos

Esta respuesta es INCORRECTA, porque PARA CADA TIPO DE INYECCIÓN, EL RESORTE UTILIZA REFLEXIÓN. Use IDE, establezca un punto de interrupción en el setter / constructor y verifique.

Esto puede ser una cuestión de gustos pero también puede ser una cuestión de CASO. @dieter proporcionó un caso excelente cuando la inyección de campo es mejor. Si está utilizando la inyección de campo en las pruebas de integración que están configurando el contexto de Spring, el argumento con la capacidad de prueba de la clase también es inválido, a menos que desee escribir más adelante en las pruebas de Sus pruebas de integración;)