qué - public interface java

Spring: ¿Por qué autoaumentamos la interfaz y no la clase implementada?

Question

Ejemplo

interface IA
{
public void someFunction();
}
@Resource(name="b")
class B implements IA
{
public void someFunction()
{
//busy code block
}
public void someBfunc()
{
//doing b things
}
}
@Resource(name="c")
class C implements IA
{
public void someFunction()
{
//busy code block
}
public void someCfunc()
{
//doing C things
}
}
class MyRunner
{
@Autowire
@Qualifier("b")
IA worker;
worker.someFunction();
}

¿Puede alguien explicarme esto?

• ¿Cómo sabe la primavera qué tipo de polimorfo usar?
• ¿Necesito @Qualifier o @Resource ?
• ¿Por qué autoaumentamos la interfaz y no la clase implementada?

Answer 1

¿Cómo sabe la primavera qué tipo de polimorfo usar?

Siempre que haya una única implementación de la interfaz y que la implementación esté anotada con @Component con la exploración de componentes de Spring habilitada, Spring Framework puede encontrar la pareja (interfaz, implementación). Si el escaneo de componentes no está habilitado, entonces debe definir el bean explícitamente en su application-config.xml (o archivo de configuración de primavera equivalente).

¿Necesito @Qualifier o @Resource?

Una vez que tiene más de una implementación, necesita calificar cada uno de ellos y durante el auto-cableado, necesitaría usar la anotación @Qualifier para inyectar la implementación correcta, junto con la anotación @Autowired . Si está utilizando @Resource (semántica J2EE), debe especificar el nombre del bean utilizando el atributo name de esta anotación.

¿Por qué autoaumentamos la interfaz y no la clase implementada?

En primer lugar, siempre es una buena práctica codificar las interfaces en general. En segundo lugar, en caso de primavera, puede inyectar cualquier implementación en tiempo de ejecución. Un caso de uso típico es inyectar una implementación simulada durante la etapa de prueba.

interface IA
{
public void someFunction();
}
class B implements IA
{
public void someFunction()
{
//busy code block
}
public void someBfunc()
{
//doing b things
}
}
class C implements IA
{
public void someFunction()
{
//busy code block
}
public void someCfunc()
{
//doing C things
}
}
class MyRunner
{
@Autowire
@Qualifier("b")
IA worker;
....
worker.someFunction();
}

La configuración de tu bean debería verse así:

<bean id="b" class="B" />
<bean id="c" class="C" />
<bean id="runner" class="MyRunner" />

De forma alternativa, si activó el análisis de componentes en el paquete en el que están presentes, debe calificar cada clase con @Component siguiente manera:

interface IA
{
public void someFunction();
}
@Component(value="b")
class B implements IA
{
public void someFunction()
{
//busy code block
}
public void someBfunc()
{
//doing b things
}
}
@Component(value="c")
class C implements IA
{
public void someFunction()
{
//busy code block
}
public void someCfunc()
{
//doing C things
}
}
@Component
class MyRunner
{
@Autowire
@Qualifier("b")
IA worker;
....
worker.someFunction();
}

Luego, al worker de MyRunner se le inyectará una instancia de tipo B

Answer 2

También puede causar algunos warnigs en registros como un método Cglib2AopProxy Imposible a proxy . Y muchas otras razones para esto se describen aquí ¿Por qué siempre tener interfaces de implementación única en servicio y capas de dao?