Bref, IoC et DI en C# (…en utilisant Windsor Castle, pour la reine ;)

Avez-vous déjà écouté l’expression « Inversion of Control (IoC) « ou « Dependency Injection (DI) « mais vous ne savez pas exactement de quoi il s’agît ou pourquoi vous pourriez en avoir besoin ? Si c’est le cas, veuillez continuer à lire chère lectrice ou cher lecteur.

Tout d’abord, il y a une grande différence entre Dependency Injection et Inversion of Control. DI c’est un patron de conception, tandis que IoC c’est plutôt un mécanisme, ou un framework utilisé pour injecter automatiquement des dépendances. Castle Windsor, c’est un exemple pour un framework IoC.

Ben alors, et c’est quoi exactement Dependency Injection maintenant ? Laissez-moi vous donner une explication simple :

dependency injection

Disons, la reine du royaume du Commonwealth visite le Canada. Pour son tour du pays, elle a besoin d’un conducteur. La reine dit à son conducteur : « Allez, on y conduit de Montréal à Toronto «.

Bien sûr, le conducteur aura besoin d’un véhicule et va alors aller en chercher un, soit un 4×4 ou soit un Rolls Royce. De toute façon, la reine n’a aucune influence sur le choix du véhicule. Et ça pourrait être un problème, surtout si le conducteur va prendre un vieux coche au lieu du Rolls Royce.

La reine et le conducteur seront insatisfaites, lui parce qu’il doit choisir, et elle à cause de son choix. C’est à dire, il y aura une relation indésirable entre le conducteur et le véhicule. Donc ça serait beaucoup mieux, si la reine pourrait donner le véhicule désiré au conducteur et disait : « Allez, Go là-bas ! «  …Non ? 😉

En tout cas, le framework IoC s’occupe de toutes les dépendances qui pourraient apparaitre dans une telle relation.

D’accord, faisons-nous une clarification du exemple au-dessus avec un codage en C#, d’abord le patron de conception Dependency Injection :

namespace DiLaReine
{
    class Program
    {
        static void Main(string[] args)
        {
        }
    }

    public class Reine
    {
        public void GiveOrder()
        {
            var charles = new Conducteur();

            var rollsRoyce = new RollsRoyce();
            var coach = new HorseBuggy();

            charles.ExecuteOrder(rollsRoyce);
            charles.ExecuteOrder(coach);
        }
    }

    public class Conducteur
    {
        public void ExecuteOrder(IDriveable vehicule)
        {
            vehicule.Drive();
        }
    }

    public interface IDriveable
    {
        void Drive();
    }

    public class RollsRoyce : IDriveable
    {
        public void Drive()
        {
        }
    }

    public class HorseBuggy : IDriveable
    {
        public void Drive()
        {
        }
    }
}

En gros…
…résumons-nous : DI c’est rien d’autre que contrôler ou résoudre des dépendances d’une mise en œuvre, en travaillant avec des interfaces par exemple. Comme ça, on peut donner une dépendance à un composant ou une classe appelé pendant la période d’action.

Et pourquoi donc tout cela ? SOLID, surtout S et O => Sinlge Responsibility Principle et Open-Closed Principle. DI/IoC fait ça donc beaucoup plus facile de maintenir les dépendances entre les objets dans une application.

Par exemple si on crée un appli pour des platforms différentes, on peut abstraire le codage commun et ajouter des spécificités d’un platform pendant la période d’action.

CASTLE WINDSOR

castle windsor

Dans notre exemple si-dessus, on pourrait dire, que Castle Windsor c’est le garage, qui s’occupe du parc de véhicules. Mais avant qu’on continue, il faut comprendre qu’il y a une différence entre Inversion of Control et Inversion of Control Container.

Inversion of Control Container

Le principe en software design IoC, est un principe où un codage custom d’un logiciel peut recevoir des instructions en regardant l’état de répétition du logiciel. Les frameworks IoC, comme par exemple Windsor, Unity, Ninject ou Spring utilisent ce principe pour maintenir les objets d’un logiciel.

Cela c’est le travail d’un Inversion of Control Container, en bref. C’est-à-dire, un IoC Container utilise le principe IoC pour maintenir les classes d’un logiciel et leur cycle vital : la création,  la destruction, la configuration et leurs dépendances. Ça a l’avantage que les classes n’ont pas besoin d’obtenir ou configure les classes dont elles dépendent. Avantage : La flexibilité et le soulagement de la réutilisation et testabilité des classes d’un logicel

Exemple en utilisant Windsor

J’utilise un appli console simple. Dans le projet, il faut ajouter un Nuget package : Castle Windsor.

windsor castle

Après il faut créer les classes, interfaces et le IoC containter avec castle windsor.

using System;
using Castle.MicroKernel.Registration;
using Castle.Windsor;
using Castle.Windsor.Installer;

namespace WindsorEtLaReine
{
    class Program
    {
        static void Main(string[] args)
        {
            IWindsorContainer cont = new WindsorContainer();
            cont.Install(FromAssembly.This());
            cont.Register(Component.For<Vehicle>());
            //cont.Register(Component.For<IDriveable>().ImplementedBy<RollsRoyce>());
            cont.Register(Component.For<IDriveable>().ImplementedBy<HorseBuggy>());

            var conducteur = cont.Resolve<Vehicle>();
            conducteur.StartEngine();

            Console.ReadKey();
        }
    }

    public class Vehicle
    {
        private IDriveable o1;

        public Vehicle(IDriveable d1)
        {
            o1 = d1;
        }

        public void StartEngine()
        {
            o1.Drive();
        }
    }

    public interface IDriveable
    {
        void Drive();
    }

    public class RollsRoyce : IDriveable
    {
        public void Drive()
        {
            Console.WriteLine("Rolls Royce drive");
        }
    }

    public class HorseBuggy : IDriveable
    {
        public void Drive()
        {
            Console.WriteLine("Attention, coach on the road...");
        }
    }
}

Cet exemple montre la base d’utilisation d’un IoC container et le patron de conception Dependency Injection. J’espère que l’exemple leve un peu le voile sur le grand sujet Dependency Injection et Inversion of Control.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *