Injection de dépendances et modèle de fabrique

Question

La plupart des exemples cités pour l'utilisation de l'injection de dépendance, nous pouvons également les résoudre en utilisant le modèle de fabrique. Il semble que lorsqu'il s'agit d'utilisation/conception, la différence entre l'injection de dépendance et la fabrique est floue ou mince.

Quelqu'un m'a dit un jour que c'est la façon dont on l'utilise qui fait la différence !

J'ai utilisé une fois StructureMap un conteneur DI pour résoudre un problème, plus tard, je l'ai redessiné pour qu'il fonctionne avec une simple usine et j'ai supprimé les références à StructureMap.

Quelqu'un peut-il me dire quelle est la différence entre eux et où utiliser quoi, quelle est la meilleure pratique ici ?

Answer 1

Lorsque vous utilisez une fabrique, votre code est toujours responsable de la création des objets. Avec DI, vous externalisez cette responsabilité à une autre classe ou à un framework, qui est séparé de votre code.

Answer 2

Je vous suggère de garder les concepts simples et clairs. L'injection de dépendances est plutôt un modèle architectural permettant de coupler librement des composants logiciels. Le Factory pattern est juste un moyen de séparer la responsabilité de la création d'objets d'autres classes à une autre entité. Le Factory pattern peut être appelé un outil pour implémenter l'injection de dépendances. L'injection de dépendances peut être mise en œuvre de nombreuses façons, par exemple en utilisant des constructeurs, des fichiers xml de mappage, etc.

Answer 3

Injection de dépendances

Au lieu d'instancier les pièces elles-mêmes, une voiture demande pour les pièces dont il a besoin pour fonctionner.

class Car
{
    private Engine engine;
    private SteeringWheel wheel;
    private Tires tires;

    public Car(Engine engine, SteeringWheel wheel, Tires tires)
    {
        this.engine = engine;
        this.wheel = wheel;
        this.tires = tires;
    }
}

Usine

Assemble les pièces pour former un objet complet et cache le type concret à l'appelant.

static class CarFactory
{
    public ICar BuildCar()
    {
        Engine engine = new Engine();
        SteeringWheel steeringWheel = new SteeringWheel();
        Tires tires = new Tires();
        ICar car = new RaceCar(engine, steeringWheel, tires);
        return car;
    }   
}

Résultat

Comme vous pouvez le constater, les usines et l'ID se complètent.

static void Main()
{
     ICar car = CarFactory.BuildCar();
     // use car
}

---

Tu te souviens de Boucle d'or et les trois ours ? Eh bien, l'injection de dépendances est un peu comme ça. Voici trois façons de faire la même chose.

void RaceCar() // example #1
{
    ICar car = CarFactory.BuildCar();
    car.Race();
}

void RaceCar(ICarFactory carFactory) // example #2
{
    ICar car = carFactory.BuildCar();
    car.Race();
}

void RaceCar(ICar car) // example #3
{
    car.Race();
}

Exemple n° 1 - C'est le pire car il masque complètement la dépendance. Si vous regardiez la méthode comme une boîte noire, vous n'auriez aucune idée qu'elle nécessite une voiture.

Exemple n° 2 - C'est un peu mieux car maintenant nous savons que nous avons besoin d'une voiture puisque nous passons dans une usine de voitures. Mais cette fois, nous passons trop de choses puisque la méthode n'a besoin que d'une voiture. Nous passons dans une usine juste pour construire la voiture alors que la voiture pourrait être construite en dehors de la méthode et passée.

Exemple n° 3 - C'est idéal car la méthode demande exactement ce dont il a besoin. Ni trop, ni trop peu. Je n'ai pas besoin d'écrire un MockCarFactory juste pour créer des MockCars, je peux passer le mock directement dedans. C'est direct et l'interface ne ment pas.

Ce Google Tech Talk de Misko Hevery est étonnant et constitue la base de ce dont j'ai tiré mon exemple. http://www.youtube.com/watch?v=XcT4yYu_TTs

Answer 4

Certains problèmes faciles à résoudre avec l'injection de dépendances ne le sont pas aussi facilement avec une suite de fabriques.

La différence entre, d'une part, l'inversion de contrôle et l'injection de dépendances (IOC/DI), et, d'autre part, un localisateur de services ou une suite de fabriques (factory), est en partie :

IOC/DI est un écosystème complet d'objets et de services de domaine en soi. Il met tout en place pour vous de la manière que vous spécifiez. Les objets et services de votre domaine sont construits par le conteneur et ne se construisent pas eux-mêmes : ils n'ont donc pas d'obligation d'intégration. tout dépendances sur le conteneur ou sur les usines. IOC/DI permet un degré de configurabilité extrêmement élevé, toute la configuration se trouvant en un seul endroit (construction du conteneur) à la couche supérieure de votre application (l'interface graphique, le front-end Web).

Factory fait abstraction d'une partie de la construction des objets et services de votre domaine. Mais les objets et services du domaine doivent toujours trouver comment se construire et comment obtenir toutes les choses dont ils dépendent. Toutes ces dépendances "actives" filtrent à travers toutes les couches de votre application. Il n'y a pas d'endroit unique où aller pour tout configurer.

Answer 5

La gestion du cycle de vie est l'une des responsabilités que les conteneurs de dépendances assument en plus de l'instanciation et de l'injection. Le fait que le conteneur conserve parfois une référence aux composants après l'instanciation est la raison pour laquelle on l'appelle un "conteneur", et non une usine. Les conteneurs d'injection de dépendances ne conservent généralement qu'une référence aux objets dont ils ont besoin pour gérer les cycles de vie, ou qui sont réutilisés pour de futures injections, comme les singletons ou les flyweights. Lorsqu'il est configuré pour créer de nouvelles instances de certains composants à chaque appel au conteneur, ce dernier oublie généralement l'objet créé.

De : http://tutorials.jenkov.com/dependency-injection/dependency-injection-containers.html