Spring: Pourquoi câblons-nous automatiquement l'interface et non la classe implémentée?

Exemple

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

Quelqu'un peut m'expliquer cela.

• Comment le ressort sait-il quel type polymorphe utiliser.
• Ai-je besoin @Qualifierou @Resource?
• Pourquoi câblons-nous automatiquement l'interface et non la classe implémentée?

Comment le ressort sait-il quel type polymorphe utiliser.

Tant qu'il n'y a qu'une seule implémentation de l'interface et que cette implémentation est annotée avec @Componentl'analyse des composants de Spring activée, Spring Framework peut trouver la paire (interface, implémentation). Si l'analyse des composants n'est pas activée, vous devez définir le bean explicitement dans votre application-config.xml (ou fichier de configuration Spring équivalent).

Ai-je besoin de @Qualifier ou @Resource?

Une fois que vous avez plusieurs implémentations, vous devez qualifier chacune d'elles et pendant le câblage automatique, vous devrez utiliser l' @Qualifierannotation pour injecter la bonne implémentation, avec l' @Autowiredannotation. Si vous utilisez @Resource (sémantique J2EE), vous devez spécifier le nom du bean à l'aide de l' nameattribut de cette annotation.

Pourquoi câblons-nous automatiquement l'interface et non la classe implémentée?

Premièrement, il est toujours recommandé de coder sur des interfaces en général. Deuxièmement, en cas de printemps, vous pouvez injecter n'importe quelle implémentation au moment de l'exécution. Un cas d'utilisation typique consiste à injecter une implémentation fictive pendant la phase de 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();
}

Votre configuration de bean devrait ressembler à ceci:

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

Sinon, si vous avez activé l'analyse des composants sur le package où ils sont présents, vous devez qualifier chaque classe @Componentcomme suit:

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

Ensuite, workerin MyRunnersera injecté avec une instance de type B.

Cela peut également provoquer des avertissements dans les journaux, comme une méthode Cglib2AopProxy Unable to proxy . Et de nombreuses autres raisons à cela sont décrites ici. Pourquoi avoir toujours des interfaces d'implémentation uniques dans les couches service et DAO?