¿El que tiene sentido en la primavera de usar @Autowired para conectar directamente a una clase concreta y no a una interfaz (y hacer uso de 'por tipo' autowiring)primavera para conectar directamente una clase concreta
Si una la clase no implementa una interfaz, ¿no sería mejor crear una instancia a través de un constructor o una fábrica (manteniendo las cosas simples); en lugar de convertirlo en un grano de primavera solo por el gusto de hacerlo.
lo hace tiene sentido en la primavera de usar
@Autowiredpara conectar directamente a una clase concreta y no a una interfaz
Claro. La práctica de autovinculación es independiente de qué está autoconectando. Funcionará con las clases al igual que con las interfaces.
Sin embargo, si es una buena idea o no es discutible, aunque esta es una pregunta más general sobre si siempre debe introducir una interfaz para una clase determinada, en lugar de hablar directamente con el tipo de clase. Los beneficios incluyen pruebas unitarias más sencillas y un diseño más limpio, a expensas del desorden de códigos.
Hay otra buena razón para Autowire tipos de interfaz en lugar de tipos de clase, que es que si la primavera necesita generar un objeto proxy en todo el frijol antes de inyectarlo, a continuación, si la clase del bean define cualquier las interfaces, entonces el proxy implementar esas interfaces, y será no ser compatible con el tipo de la propia clase de bean. Si luego intentas conectar automáticamente ese bean por tipo de clase, fallará. La forma más fácil de evitar este escenario molesto es autocabilizar siempre por tipo de interfaz, de esa manera siempre funcionará como usted espera.
y hacer uso de 'por tipo' Autowiring
Si se refiere a container-level byType autowiring, entonces usted no quiere hacer eso. Es el antiguo estilo Spring 1.x de autoenlace, y es altamente inflexibile (ver limitations of autowiring).
Stick con @Autowired, es mucho más flexible y fácil de controlar.
Si una clase no implementa una interfaz, ¿no sería mejor crear una instancia a través de un constructor o una fábrica (manteniendo las cosas simples); en lugar de convertirlo en un grano de primavera solo por el gusto de hacerlo.
Las dos preguntas están completamente separadas. Un objeto debe convertirse en Spring Bean si necesita que Spring controle sus dependencias y su ciclo de vida, independientemente de si implementa interfaces o no.Si encuentra que el objeto no tiene dependencias y no tiene una interfaz significativa, tal vez no haya razón para convertirlo en un frijol.
Tendrá que decidir si está bien instalar esta dependencia en otras clases. Por ejemplo, ¿cuántas clases diferentes es probable que requieran esta dependencia? Si la respuesta es múltiple, creará muchas instancias de esta clase donde solo se requiere una.
Además, ¿qué dependencias tiene esta clase concreta? Deberá configurar aquellos dentro de la clase que depende de él.
El objeto de dependency injection es reducir las dependencias entre las clases y hacer que su código se acople de manera flexible.