Dependency Injection vs. Factory Pattern

Question

Die meisten der Beispiele, die für die Verwendung von Dependency Injection angeführt werden, können wir auch mit dem Factory Pattern lösen. Es sieht so aus, als ob der Unterschied zwischen Dependency Injection und Factory bei der Verwendung/Entwicklung verschwommen oder dünn ist.

Jemand hat mir einmal gesagt, dass es darauf ankommt, wie man es benutzt!

Ich habe einmal StructureMap einen DI-Container, um ein Problem zu lösen. Später habe ich ihn so umgestaltet, dass er mit einer einfachen Fabrik funktioniert und die Verweise auf StructureMap entfernt.

Kann mir jemand sagen, was der Unterschied zwischen ihnen ist und wo was zu verwenden ist, was die beste Praxis hier?

Answer 1

Wenn Sie eine Fabrik verwenden, ist Ihr Code immer noch für die Erstellung von Objekten verantwortlich. Mit DI lagern Sie diese Verantwortung an eine andere Klasse oder ein Framework aus, das von Ihrem Code getrennt ist.

Answer 2

Ich würde vorschlagen, die Konzepte klar und einfach zu halten. Dependency Injection ist eher ein Architekturmuster für die lose Kopplung von Softwarekomponenten. Das Factory-Muster ist nur eine Möglichkeit, die Verantwortung für die Erstellung von Objekten anderer Klassen auf eine andere Einheit zu übertragen. Das Factory-Pattern kann als ein Werkzeug zur Implementierung von DI bezeichnet werden. Dependency Injection kann auf viele Arten implementiert werden, wie z.B. DI mit Konstruktoren, mit Mapping-Xml-Dateien usw.

Answer 3

Injektion von Abhängigkeiten

Anstatt die Teile selbst zu instanziieren, wird ein Auto fragt für die Teile, die es zum Funktionieren braucht.

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;
    }
}

Fabrik

Fügt die Teile zu einem vollständigen Objekt zusammen und verbirgt den konkreten Typ vor dem Aufrufer.

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;
    }   
}

Ergebnis

Wie Sie sehen können, ergänzen sich Fabriken und DI.

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

---

Erinnerst du dich an Goldlöckchen und die drei Bären? Nun, mit der Dependency Injection ist es so eine Sache. Hier sind drei Möglichkeiten, das Gleiche zu tun.

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();
}

Beispiel 1 - Das ist das Schlimmste, weil es die Abhängigkeit völlig verdeckt. Wenn Sie die Methode als Blackbox betrachten würden, wüssten Sie nicht, dass sie ein Auto benötigt.

Beispiel #2 - Das ist schon etwas besser, denn jetzt wissen wir, dass wir ein Auto brauchen, da wir in einer Autofabrik vorbeikommen. Aber dieses Mal übergeben wir zu viel, denn alles, was die Methode wirklich braucht, ist ein Auto. Wir übergeben eine Fabrik, nur um das Auto zu bauen, wenn das Auto auch außerhalb der Methode gebaut und übergeben werden könnte.

Beispiel #3 - Dies ist ideal, da die Methode folgende Fragen stellt genau was es braucht. Nicht zu viel und nicht zu wenig. Ich muss keine MockCarFactory schreiben, nur um MockCars zu erstellen, ich kann den Mock direkt übergeben. Es ist direkt und die Schnittstelle lügt nicht.

Dieser Google Tech Talk von Misko Hevery ist erstaunlich und bildet die Grundlage für mein Beispiel. http://www.youtube.com/watch?v=XcT4yYu_TTs

Answer 4

Der Grund für die Ähnlichkeit von Dependency Injection (DI) und Factory Patterns liegt darin, dass es sich um zwei Implementierungen von Inversion of Control (IoC) handelt, also einer Softwarearchitektur. Einfach ausgedrückt sind sie zwei Lösungen für dasselbe Problem.

Um die Frage zu beantworten: Der Hauptunterschied zwischen dem Factory-Muster und DI besteht darin, wie die Objektreferenz erhalten wird. Bei der Dependency Injection wird, wie der Name schon sagt, der Verweis in den Code injiziert oder gegeben. Beim Factory-Muster muss Ihr Code die Referenz anfordern, damit Ihr Code das Objekt abruft. Bei beiden Implementierungen wird die Verknüpfung zwischen dem Code und der zugrundeliegenden Klasse oder dem Typ des Objektverweises, der vom Code verwendet wird, entfernt oder entkoppelt.

Es ist erwähnenswert, dass Factory-Muster (oder auch Abstract Factory-Muster, die Fabriken sind, die neue Fabriken zurückgeben, die Objektreferenzen zurückgeben) geschrieben werden können, um dynamisch den Typ oder die Klasse des Objekts auszuwählen oder zu verknüpfen, das zur Laufzeit angefordert wird. Damit sind sie dem Service-Locator-Muster sehr ähnlich (sogar noch mehr als DI), das eine weitere Implementierung von IoC ist.

Das Factory-Entwurfsmuster ist ziemlich alt (in Bezug auf Software) und gibt es schon eine Weile. Seit der jüngsten Popularität des Architekturmusters IoC erlebt es ein Wiederaufleben.

Ich schätze, wenn es um IoC-Entwurfsmuster geht: Injektoren sind Injektoren, Locatoren sind Locatoren und die Fabriken wurden refaktorisiert.

Answer 5

Es gibt Probleme, die mit Dependency Injection leicht zu lösen sind, die mit einer Reihe von Factories nicht so leicht zu lösen sind.

Der Unterschied zwischen der Umkehrung der Kontrolle und der Injektion von Abhängigkeiten (IOC/DI) einerseits und einem Service-Locator oder einer Reihe von Fabriken (Factory) andererseits besteht unter anderem darin, dass es sich dabei um eine Kombination aus zwei Komponenten handelt:

IOC/DI ist ein vollständiges Ökosystem von Domänenobjekten und -diensten in sich selbst. Es richtet alles für Sie so ein, wie Sie es angeben. Ihre Domänenobjekte und -dienste werden durch den Container konstruiert und konstruieren sich nicht selbst: Sie haben daher keine cualquier Abhängigkeiten vom Container oder von irgendwelchen Fabriken. IOC/DI ermöglicht ein extrem hohes Maß an Konfigurierbarkeit, wobei die gesamte Konfiguration an einer einzigen Stelle (Konstruktion des Containers) auf der obersten Schicht Ihrer Anwendung (der grafischen Benutzeroberfläche, dem Web-Frontend) erfolgt.

Factory abstrahiert einen Teil der Konstruktion Ihrer Domänenobjekte und -dienste. Aber die Domänenobjekte und -dienste sind immer noch dafür verantwortlich, herauszufinden, wie sie sich selbst konstruieren und wie sie all die Dinge erhalten, von denen sie abhängig sind. All diese "aktiven" Abhängigkeiten ziehen sich durch alle Schichten Ihrer Anwendung hindurch. Es gibt keinen einzigen Ort, an dem man alles konfigurieren kann.