2
respuestas

[Duda] Reemplazo de Autowired

Durante este curso, también cómo los anteriores; estuvieron diciendo que la etiqueta @Autowired no es una buena costumbre, pero aún así no me queda claro el motivo explícito por el cual utilizarla es una mala práctica y tampoco qué reemplazo se le podría dar para aferrarse a las buenas costumbres de programación.

2 respuestas

La etiqueta @Autowired en el contexto de Spring Framework se utiliza para realizar la inyección de dependencias automáticamente en los componentes de una aplicación. Aunque no es necesariamente una "mala práctica", existen argumentos para evitar su uso en ciertos casos y preferir otras formas de inyección de dependencias. Aquí están algunas de las razones por las cuales algunas personas consideran que @Autowired puede no ser la mejor opción en todos los casos:

  1. Acoplamiento fuerte: El uso excesivo de @Autowired puede llevar a un acoplamiento fuerte entre los componentes de tu aplicación. Esto significa que tus clases estarán fuertemente ligadas a las implementaciones concretas de las dependencias, lo que dificulta la prueba y la reutilización de esas clases.
  2. Falta de claridad: En algunos casos, cuando ves @Autowired en una clase, puede ser difícil determinar de inmediato de dónde provienen las dependencias. Esto puede dificultar la comprensión del código y el seguimiento de las dependencias.
  3. Menos control: Al utilizar @Autowired, estás delegando la resolución de dependencias a Spring Framework, lo que significa que tienes menos control sobre cómo se resuelven esas dependencias. En situaciones donde necesitas un control más granular o condicional sobre la inyección de dependencias, @Autowired puede ser limitante.
  4. Principio de inversión de dependencia (DIP): El principio de inversión de dependencia sugiere que las dependencias deben depender de abstracciones en lugar de implementaciones concretas. Al utilizar @Autowired, a menudo se inyectan las implementaciones concretas, lo que va en contra de este principio.
  5. Problemas de pruebas unitarias: Al depender en exceso de @Autowired, puede ser complicado escribir pruebas unitarias, ya que las dependencias se inyectan automáticamente. En cambio, preferir la inyección de dependencias explícita mediante constructores o métodos de configuración facilita la escritura de pruebas unitarias.

Por qué podría optar en caso de no querer utilizar esa etiqueta o que no sea lo mas eficiente para mi código?