Injection de dépendances en .Net Core [ Partie 1 : Introduction ]

Tout développeur a déjà probablement entendu parler d’injection de dépendances. Cependant, certains n’y voit pas d’utilité, souvent dû à l’incompréhension de ce principe. C’est pourtant devenu une bonne pratique de nos jours de l’utiliser dans nos développements. Ce dernier apporte les avantages suivants :

• Maintenance : Le principe de l’injection de dépendance est d’avoir des couplages légers entre nos différentes classes, et de favoriser le principe de responsabilité unique. Avoir plusieurs classes simples qui n’ont qu’une seule responsabilité est beaucoup plus facile à maintenir que d’avoir des classes compliquées et étroitement liée à ses dépendances. Et comme nous passons souvent plus de temps à maintenir une application qu’a l’écrire, c’est un avantage non négligeable.
• Lisibilité : Indirectement lié au point ci-dessous, le principe de responsabilité unique augmente la lisibilité du code. Il est plus facile d’intervenir dans une classe plus petite qui à sa propre responsabilité, que de rechercher une partie de code dans une classe complexe.
• Testabilité : L’injection de dépendance permet d’écrire des tests unitaires, puisqu’il supprime la dépendance lourde entre les classes. Et avoir des classes à responsabilités uniques est plus facile à tester que des classes complexes.

Afin de bien comprendre les points ci-dessus, prenons un exemple concret. Imaginons un programme pour un garage qui vend des voitures Opel et prenons le temps d’analyser le bout de code suivant :

public class MainView
{
    public List<string> GetCarList()
    {
        var opelService = new OpelService();
        return opelService.GetCarNameList();
    }
}

Rien de bien compliqué, une simple méthode qui retourne le résultat de la méthode GetCarNameList() de la classe OpelService. Le point qui est embêtant, c’est qu’avant de retourner le résultat, la méthode doit instancier la classe OpelService. Cette instanciation crée une dépendance forte entre la classe MainView et la classe OpelService. Cette dépendance forte entraine les désavantages suivants :

Si demain le garage veut vendre des voitures de marque Audi plutôt que des voitures de marque Opel, il faudra aller modifier toutes les classes qui utilisent OpelService pour les remplacer par AudiService
Si le constructeur de OpelService change de signature, il faut aller modifier toutes les instanciations de OpelService dans l’application
Si l’on souhaite écrire un test unitaire sur notre méthode, il est impossible de mocker la classe OpelService
Notre méthode ne respecte pas le S des principes SOLID vu qu’elle s’occupe non seulement de retourner la liste des noms de voitures, mais aussi d’instancier la classe Opel Service

C’est ici que l’injection de dépendance entre en jeu. Elle va permettre à notre classe de ne pas avoir à se soucier de l’instanciation de ces dépendances. Dans la partie deux, nous allons voir comment nous pouvons la mettre en place.