The .Net frog

On m'a récemment demandé de citer un pattern que j'utilise systématiquement dans mes projets. Question difficile dans la mesure ou un pattern ne doit justement pas être appliqué mécaniquement : son utilisation est conditionnée par le contexte.

Pourtant, apres réflexion, il y a bien un pattern que j'utilise de façon systématique : l'injection des dépendances qui est un application d'un pattern plus global appelé inversion de contrôle (Dependency Injection et Inversion of Control en anglais, ou DI et IoC).

L'inversion de contrôle est un concept assez générique. Il permet à un framework de déléguer l'implémentation et l'exécution d'un comportement à du code qui n'est pas lui même contenu dans le framework. Plusieurs façons existent pour appeler le code en question, comme :

• La programmation orientée évenement : le code appelant le framework à la possibilité de se lier à certains évènements pour effectuer des opérations quand ces derniers sont levés. On retrouve cet architecture à tous les étages du framework .Net.
• Le pattern "Template method" : une classe abstraite définie une fonction qui appelle un certain nombre de méthodes virtuelles. Celles ci peuvent doivent être implémentées dans une classe fille pour définir le comportement.
• L'injection des dépendances, que je vais expliquer dans les lignes qui suivent :-)

L'injection des dépendances :

Un programme informatique comprends généralement un ensemble plus ou moins complexe de dépendances entre différentes classes. Par exemple, nous pourrions envoyer un email avec le code suivant :

class Controller
{
    public void DoStuff()
    {
        var emailSender = new EmailSender();
        emailSender.Send("j@j.com", "Email Subject", "This is the content !");
    }
}
 
class EmailSender
{
    public void Send(string to, string subject, string message)
    {
        // Send the email...
    }
}

Nous venons de créer une relation de dépendance forte entre la classe Controller et la classe EmailSender. Cependant, l'envoi d'email est un service qui peut avoir de nombreuses implémentations. On pourrait par exemple avoir une implémentation utilisant la classe System.Net.Mail.SmtpClient et une seconde utilisant un prestataire externe par l'intermédiaire de web services. Qui plus est, on peut envisager d'utiliser la première implémentation en test et la seconde en production. Autrement dit, nous ferions mieux de refactorer ce code pour découpler Controller d'une implémentation spécifique d'EmailSender !

Première étape de notre refactoring, EmailSender doit implémenter un contrat (une interface) :

interface IEmailSender
{
    void Send(string to, string subject, string message);
}
 
class EmailSender : IEmailSender
{
    public void Send(string to, string subject, string message)
    {
        // Send the email...
    }
}

Deuxième étape : remplacer la dépendance Controller <-> EmailSender par Controller <-> IEmailSender :

class Controller
{
    private IEmailSender _emailSender;
 
    public void DoStuff()
    {
        _emailSender.Send("j@j.com", "Email Subject", "This is the content !");
    }
}

A cet instant, la classe Controller ne dépend plus d'une implémentation spécifique d'EmailSender. Nous avons donc appliqué le pattern inversion de contrôle. Dernière étape : injecter l'implémentation voulue dans la classe Controller, par l'intermédiaire du constructeur :

class Controller
{
    private IEmailSender _emailSender;
 
    public Controller(IEmailSender emailSender)
    {
        _emailSender = emailSender;
    }
 
    public void DoStuff()
    {
        _emailSender.Send("j@j.com", "Email Subject", "This is the content !");
    }
}

(Remarque : l'injection peut aussi être faite par l'intermédiaire d'une propriété)

Et ça y est, nous venons d'appliquer l'injection de dépendances !

L'utilisation de ce pattern offre plusieurs bénéfices immédiats :

• Nous l'avons déjà vu, Controller ne dépend plus d'une implémentation spécifique. Il est donc facile de passer d'une implémentation à une autre en fonction du contexte
• La dépendance entre Controller et IEmailSender est explicite, le code devient plus maintenable et compréhensible
• Si la dépendance est exposée, il est possible de la remplacer par une implémentation factice pour écrire des tests unitaires
• Enfin, la configuration des dépendances peut maintenant être centralisée et effectuée par l'intermédiaire un framework (StructureMap, Spring.Net, Castle, NInject, etc.).

Ces deux derniers points feront l'objet d'un billet prochainement :-).