L'injection de dépendances (`@Autowired`, injection par constructeur, setter, champ)

Introduction à l'Injection de Dépendances (DI)

L'Injection de Dépendances (Dependency Injection - DI) est un patron de conception et une forme spécifique d'Inversion de Contrôle (IoC). Au lieu qu'un objet crée lui-même ses dépendances (les autres objets dont il a besoin pour fonctionner) ou les recherche activement (par exemple via un lookup JNDI ou un registre statique), ces dépendances lui sont fournies (injectées) par une entité externe : le conteneur IoC de Spring.

Pourquoi est-ce si important ? L'injection de dépendances favorise le couplage faible entre les composants. Un objet n'a plus besoin de connaître les détails de la création ou de la localisation de ses dépendances, seulement l'interface ou la classe dont il a besoin. Cela rend les composants plus indépendants, plus faciles à remplacer, à configurer et surtout, beaucoup plus faciles à tester unitairement (car on peut injecter des objets mockés ou bouchonnés).

Spring propose plusieurs façons de réaliser l'injection de dépendances, principalement basées sur l'annotation @Autowired.

L'annotation `@Autowired`

L'annotation org.springframework.beans.factory.annotation.Autowired est le mécanisme standard de Spring pour marquer un point d'injection. Elle indique au conteneur Spring qu'il doit automatiquement fournir (injecter) une instance de bean appropriée à cet endroit.

@Autowired peut être placée sur :

• Des constructeurs
• Des méthodes (typiquement des setters)
• Des champs (attributs de classe)
• Des paramètres de méthode (dans des cas plus spécifiques, souvent dans les méthodes @Bean des classes @Configuration)

Par défaut, Spring considère que la dépendance marquée par @Autowired est obligatoire. Si le conteneur ne trouve pas de bean correspondant au type requis, il lèvera une exception au démarrage (NoSuchBeanDefinitionException). Vous pouvez rendre une dépendance optionnelle en utilisant @Autowired(required = false). Dans ce cas, si aucun bean correspondant n'est trouvé, Spring laissera simplement la dépendance à null sans lever d'erreur.

Injection par Constructeur

C'est la méthode d'injection recommandée par l'équipe Spring, en particulier pour les dépendances obligatoires.

Mécanisme : Les dépendances sont déclarées comme paramètres du constructeur de la classe. L'annotation @Autowired est placée sur le constructeur.

@Service
public class OrderService {

    private final ProductRepository productRepository;
    private final CustomerNotificationService notificationService;

    // @Autowired est implicite et optionnelle ici car il n'y a qu'un seul constructeur (depuis Spring 4.3)
    // @Autowired 
    public OrderService(ProductRepository productRepository, CustomerNotificationService notificationService) {
        this.productRepository = productRepository;
        this.notificationService = notificationService;
    }

    // ... méthodes métier utilisant les dépendances
}

Avantages :

• Garantie des dépendances : L'objet est créé dans un état valide avec toutes ses dépendances obligatoires. Il ne peut pas exister sans elles.
• Immutabilité : Permet de déclarer les champs de dépendance comme final, ce qui renforce l'immutabilité et la sécurité du thread (thread-safety).
• Testabilité : Très facile à tester unitairement. Il suffit d'instancier la classe manuellement en passant des implémentations mockées ou bouchonnées au constructeur, sans avoir besoin du conteneur Spring.
• Clarté : Les dépendances sont clairement listées comme paramètres du constructeur. Un constructeur avec trop de paramètres est un signe potentiel que la classe a trop de responsabilités (violation du Single Responsibility Principle).
• Gestion des dépendances circulaires : Les dépendances circulaires (Bean A dépend de Bean B, qui dépend de Bean A) provoquent une erreur explicite au démarrage lors de l'utilisation de l'injection par constructeur, ce qui vous oblige à revoir la conception (ce qui est généralement une bonne chose).

Inconvénient : Ne convient pas bien aux dépendances optionnelles ou pour permettre la réinjection après construction (ce qui est rarement nécessaire).

Injection par Setter

Mécanisme : Les dépendances sont fournies via des méthodes setter publiques. L'annotation @Autowired est placée sur la méthode setter.

@Service
public class ReportGenerator {

    private FormattingService formattingService; // Dépendance optionnelle
    private DataSource dataSource; // Dépendance obligatoire (pour l'exemple)

    // Injection obligatoire via constructeur
    @Autowired
    public ReportGenerator(DataSource dataSource) {
        this.dataSource = dataSource;
    }

    // Injection optionnelle via setter
    @Autowired(required = false)
    public void setFormattingService(FormattingService formattingService) {
        this.formattingService = formattingService;
    }

    public void generateReport() {
        // ... utilise dataSource
        if (formattingService != null) {
            // ... utilise formattingService
        }
    }
}

Avantages :

• Dépendances optionnelles : C'est le cas d'usage principal. Permet d'injecter une dépendance si elle est disponible, mais l'objet peut fonctionner (éventuellement avec des fonctionnalités réduites) même sans elle.
• Réinjection / Reconfiguration : Théoriquement possible, mais généralement déconseillé dans le modèle de bean singleton par défaut de Spring.

Inconvénients :

• Etat potentiellement incohérent : L'objet est d'abord construit (potentiellement sans certaines dépendances), puis les setters sont appelés. Il existe une fenêtre où l'objet n'est pas entièrement initialisé.
• Ne permet pas les champs `final` : Les dépendances injectées par setter ne peuvent pas être déclarées final.
• Moins clair : Les dépendances sont disséminées dans plusieurs méthodes setter.
• Testabilité légèrement réduite : Il faut appeler explicitement les setters après avoir créé l'objet dans les tests unitaires.

Injection par Champ

Mécanisme : L'annotation @Autowired est placée directement sur le champ (attribut) de la classe. Spring utilise la réflexion pour définir la valeur du champ, même s'il est privé.

@Service
public class DataProcessor {

    @Autowired
    private ValidatorService validator;

    @Autowired
    private PersistenceService persistence;

    // Pas de constructeur explicite nécessaire pour l'injection ici
    // (un constructeur par défaut implicite est utilisé par Spring)

    public void process(Data data) {
        if (validator.isValid(data)) {
            persistence.save(data);
        }
    }
}

Avantages :

• Conciseness : C'est la forme la plus concise, nécessitant le moins de code boilerplate.

Inconvénients :

• Violation de l'encapsulation : Permet au conteneur d'accéder directement aux champs privés, contournant les méthodes d'accès.
• Testabilité fortement réduite : Très difficile à tester unitairement sans le conteneur Spring. Pour injecter des mocks, il faut utiliser la réflexion dans les tests ou s'appuyer sur des frameworks de test spécifiques à Spring (@MockBean).
• Dépendances cachées : Les dépendances ne sont pas visibles dans le contrat public de la classe (constructeur ou setters).
• Ne permet pas les champs `final` : Impossible de déclarer les dépendances comme final.
• Problèmes avec les dépendances circulaires : Peut masquer des dépendances circulaires qui ne seraient détectées qu'au moment de l'exécution.

Conclusion : L'injection par champ est fortement déconseillée pour les composants applicatifs. Sa concision ne compense pas ses nombreux inconvénients, notamment en matière de testabilité et de respect des principes de conception objet. Elle peut être tolérable dans les classes de test (avec @Autowired ou @MockBean), mais doit être évitée dans le code de production.

Gestion de l'ambiguïté : `@Qualifier` et `@Primary`

Que se passe-t-il si plusieurs beans correspondent au type requis par @Autowired ? Par défaut, Spring lèvera une exception (NoUniqueBeanDefinitionException).

Pour résoudre cette ambiguïté, vous avez deux options principales :

• @Primary : Vous pouvez marquer l'une des implémentations de bean comme étant la candidate principale (primaire). Si plusieurs beans correspondent au type, celui marqué @Primary sera choisi par défaut.

  @Component
  @Primary // Ce bean sera choisi par défaut pour l'interface MessageService
  public class EmailService implements MessageService { /* ... */ }
  
  @Component
  public class SmsService implements MessageService { /* ... */ }
  

• @Qualifier("beanName") : Vous pouvez spécifier explicitement le nom du bean que vous souhaitez injecter en utilisant l'annotation @Qualifier conjointement avec @Autowired.

  @Component("emailSender") // Nom explicite du bean
  public class EmailService implements MessageService { /* ... */ }
  
  @Component("smsSender") // Autre nom
  public class SmsService implements MessageService { /* ... */ }
  
  @Service
  public class NotificationManager {
      private final MessageService primaryMessageService;
      private final MessageService smsMessageService;
  
      @Autowired
      public NotificationManager(
          MessageService primaryMessageService, // Injectera EmailService car @Primary
          @Qualifier("smsSender") MessageService smsMessageService // Injectera SmsService par son nom
      ) {
          this.primaryMessageService = primaryMessageService;
          this.smsMessageService = smsMessageService;
      }
  }
  

Le choix entre @Primary et @Qualifier dépend du contexte. @Primary est utile pour définir un choix par défaut global, tandis que @Qualifier permet une sélection spécifique au point d'injection.