He estado desarrollando en Spring Boot durante poco más de un año, pero aún no he entendido los beneficios de usar un constructor Autowired y me preguntaba si alguien podría explícame esto y lo que se consideraría una mejor práctica.
Digamos que tengo un bean de la siguiente manera
@Component public class MyBean { void doSomeStuff() { } } Y tengo un servicio que tiene una dependencia en ese bean
@Service public class MyServiceImpl implements MyService { private MyBean myBean; } Para mí, la forma más sencilla de inyectar la dependencia en esta clase sería simplemente anotar la variable con @Autowired
@Service public class MyServiceImpl implements MyService { @Autowired private MyBean myBean; } Pero hay otros lugares en línea (y también otros desarrolladores de mi equipo) que favorecen algo como este enfoque:
@Service public class MyServiceImpl implements MyService { private MyBean myBean; @Autowired public MyServiceImpl(MyBean myBean) { this.myBean = myBean; } } Para mí, usar un constructor como ese es simplemente código redundante. Conectar automáticamente el bean es mucho más simple y directo que lo que me parece un código estándar.
Comentarios
Responder
Utiliza un real constructor por las mismas razones por las que utiliza captadores y definidores públicos en lugar de hacer públicas las variables privadas.
Algunos ejemplos de la vida real: los teléfonos móviles no están permitidos en ubicaciones físicas seguras y sensibles a la información. Cualquier comunicación con esa ubicación segura debe tener lugar a través de un protocolo de comunicaciones encriptado, controlado y establecido de forma segura, no subrepticiamente por un canal de comunicaciones no supervisado e incontrolado.
En un concierto, no permite que las personas arrojar cosas por encima de la cerca a alguien que ya está en el estadio. Cualquier cosa que entre o salga debe pasar por una puerta.
Si eso es todo lo que hay en su ejemplo de código, entonces aparece como un texto repetitivo innecesariamente detallado. Pero con frecuencia hacemos otras cosas en el constructor además de configurar variables privadas, como la validación. En muchos lenguajes de programación, cambiar la forma en que se hace esto después del hecho es un cambio de ruptura binaria, por lo que proporcionar el constructor por adelantado puede ser un paso sensato.
Finalmente, la clase debería poder funcionar independientemente de la inyección de dependencia. Si coloca una anotación en un miembro privado, pero no incluye un constructor , esencialmente ha vinculado estrechamente esa clase al contenedor DI, y la clase no funcionará sin él.
Comentarios
- " En un concierto, no ' no permite que la gente arroje cosas por encima de la cerca a alguien que ' s ya en el stadiu metro. Todo lo que entre o salga debe pasar por una puerta. " Pero no ' veo cómo el uso de un constructor hace que el cableado automático sea más seguro. Si no hubiera requisitos del constructor (como la validación), ¿sería beneficioso utilizar un constructor?
- Hace posible agregar validación más adelante sin romper la compatibilidad binaria.
- También , tenga en cuenta que los miembros privados realmente deberían permanecer privados. Eso ' es un poco el objetivo de tener miembros privados.
- El punto es permitir buenas prácticas de diseño compatibles con @Autowire. Tener constructores es lo MÁS natural en POO. Por el contrario, (lo que usted llama sencillo y sencillo) da algo de miedo. No hay beneficios reales en la eliminación de constructores, ' no tiene simplicidad en absoluto. Los constructores se encuentran entre los métodos más simples de POO.Per se, generalmente tienen muy poca complejidad que valga la pena implementar la magia de Spring IoC
- Por lo que ' s vale, Java tiende a ser un muy lenguaje muy detallado de todos modos. Si ' está buscando dominar algo de esa verbosidad, no es probable que la eliminación de constructores haga mucho impacto.
To me, using a constructor like that is simply redundant code. Autowiring the bean is much simpler and straightforward than what appears to me to be boilerplate code.y ¿no le preocupa la magia de inyectar un bean en una variable de instancia que es privada y no tiene setter? ¿No les preocupa la enorme deuda técnica que esto les genera a ustedes, sus compañeros de trabajo? ¿No te preocupa transmitir demasiado el paradigma mágico de Spring ' en lugar de las buenas prácticas de diseño?