Spring: Perché eseguiamo l'autowire dell'interfaccia e non la classe implementata?

Question

Esempio

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(); 
} 

Qualcuno può spiegare questo a me.

• Come fa la molla a sapere quale tipo di polimero utilizzare.
• Ho bisogno di @Qualifier o @Resource?
• Perché automatizziamo l'interfaccia e non la classe implementata?

Answer 1

Come fa la molla a sapere quale tipo di polimero utilizzare.

Finché c'è solo una singola implementazione dell'interfaccia e che l'attuazione è annotata con @Component con l'esplorazione componente di Primavera abilitato, framework Spring può scoprire il (interfaccia, implementazione) coppia. Se la scansione dei componenti non è abilitata, è necessario definire esplicitamente il bean nel file application-config.xml (o in un file di configurazione Spring equivalente).

Ho bisogno di @Qualifier o @Resource?

Una volta che avete più di un'implementazione, allora avete bisogno di qualificare ciascuno di loro e durante auto-cablaggio, si avrebbe bisogno di utilizzare il @Qualifier annotazioni di iniettare il diritto attuazione, oltre a @Autowired annotazione. Se si utilizza @Resource (semantica J2EE), è necessario specificare il nome del bean utilizzando l'attributo name di questa annotazione.

Perché si automatizza l'interfaccia e non la classe implementata?

In primo luogo, è sempre buona norma codificare le interfacce in generale. In secondo luogo, in caso di primavera, è possibile iniettare qualsiasi implementazione in fase di esecuzione. Un tipico caso d'uso è quello di iniettare un'implementazione fittizia durante la fase di test.

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 configurazione di fagioli dovrebbe assomigliare a questa:

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

In alternativa, se è stata abilitata la scansione dei componenti sulla confezione dove queste sono presenti, allora si dovrebbe qualificare ogni classe con @Component come segue:

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(); 
} 

Quindi worker in MyRunner verrà iniettato con un'istanza di tipo B.

Answer 2

Inoltre può causare alcuni avvisi nei registri come un Cglib2AopProxy Unable to proxy method. E molti altri motivi sono descritti qui Why always have single implementaion interfaces in service and dao layers?