490 votes

Injection de dépendance vs Pattern Factory

La plupart des exemples cités pour l'utilisation de l'Injection de Dépendance, nous pouvons résoudre en utilisant le modèle de fabrique. Ressemble quand il s'agit de l'utilisation/de la conception de la différence entre l'injection de dépendance et l'usine est floue ou mince.

Une fois quelqu'un m'a dit que sa manière de l'utiliser qui fait la différence!

Une fois, j'ai utilisé StructureMap un conteneur d'injection de dépendances pour résoudre un problème, plus tard, j'ai repensé pour qu'il fonctionne avec une simple usine et a supprimé les références à StructureMap.

Quelqu'un peut me dire quelle est la différence entre eux et ce, quelle est la meilleure pratique ici?

287voto

willcodejavaforfood Points 20365
<p>Lorsque vous utilisez une usine votre code est toujours effectivement responsable de la création d’objets. Par DI vous confier cette responsabilité à une autre classe ou un cadre, qui est séparé de votre code.</p>

217voto

Perpetualcoder Points 7381
<p>Je dirais pour garder les notions purement et simplement. Injection de dépendance est plus d’un modèle architectural de couplage lâche de composants logiciels. Pattern Factory est juste un moyen de séparer la responsabilité de créer les objets des autres classes à une autre entité. Modèle de fabrique peut être appelé comme un outil pour mettre en œuvre des DI. Injection de dépendance peut être implémentée à bien des égards comme DI à l’aide de constructeurs, à l’aide de fichiers de mappage xml etc..</p>

181voto

Despertar Points 5365

Depency Injection

Au lieu d'instancier les pièces lui-même une voiture demande pour les pièces il a besoin pour fonctionner.

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

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

Usine

Met les morceaux ensemble pour en faire un objet complet et cache ce type de béton à partir de 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 voir, les Usines et les DI complètent les uns les autres.

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

Vous souvenez-vous de boucle d'or et les trois ours? Bien d'injection de dépendance 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 #1 - C'est le pire, car il cache complètement la dépendance. Si vous avez regardé la méthode comme une boîte noire vous n'avez aucune idée il fallait une voiture.

Exemple #2 - C'est un peu mieux, parce que maintenant nous savons que nous avons besoin d'une voiture, car nous passons dans une usine de voitures. Mais cette fois, nous passons trop de depuis tous la méthode réellement besoin d'une voiture. Nous sommes de passage dans une usine, il suffit de construire la voiture lorsque la voiture peut être construit en dehors de la méthode et de passé en.

Exemple #3 - C'est idéal parce que la méthode demande exactement ce dont il a besoin. Ni trop, ni trop peu. Je n'ai pas à écrire un MockCarFactory juste pour créer MockCars, je peux passer la fausse droite. Il est direct et l'interface n'est pas mentir.

Ce Google de Parler de Technologie par Misko Hevery est incroyable et est la base de ce que j'ai tiré de mon exemple. http://www.youtube.com/watch?v=XcT4yYu_TTs

39voto

yfeldblum Points 42613

Il y a des problèmes qui sont faciles à résoudre avec l'injection de dépendance qui ne sont pas si facilement résolu avec une suite des usines.

Une partie de la différence entre, d'une part, l'inversion de contrôle et l'injection de dépendance (CIO/DI), et, d'autre part, un localisateur de service ou d'un ensemble d'usines (usine), est:

CIO/DI est un écosystème complet d'objets de domaine et services dans et de lui-même. Il met tout en place pour vous dans le chemin que vous spécifiez. Votre domaine d'objets et de services sont construits par le conteneur, et de ne pas construire eux-mêmes: ils n'ont donc pas toutes les dépendances sur le contenant ou sur toutes les usines. CIO/DI permet un très haut degré de configurabilité, avec toute la configuration dans un seul endroit (la construction du conteneur) à la couche supérieure de votre application (l'interface graphique, le Web front-end).

Usine abstraction de certains de la construction de votre domaine d'objets et de services. Mais le domaine des objets et des services sont encore responsable de trouver comment construire eux-mêmes et de la façon d'obtenir toutes les choses qu'ils dépendent. Tous ces "actifs" dépendances filtre tout le chemin à travers toutes les couches de votre application. Il n'y a pas un seul endroit où aller pour tout configurer.

22voto

Pup Points 3505

Gestion du cycle de vie est l'une des responsabilités de la dépendance des conteneurs assumer en plus de l'instanciation et l'injection. Le fait que le récipient parfois de conserver une référence pour les composants après l'instanciation est la raison pour laquelle il est appelé un "conteneur", et pas une usine. L'injection de dépendance des conteneurs habituellement seulement de conserver une référence à des objets, des besoins pour gérer les cycles de vie, ou qui sont réutilisées pour l'avenir des injections, comme des singletons ou de disques centrifuges. Lorsqu'il est configuré pour créer de nouvelles instances de certains composants pour chaque appel du conteneur, le conteneur habituellement juste oublie de l'objet créé.

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

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X