Laut SOLID-Prinzipien kann eine Klasse nicht von anderen Klassen abhängen, Abhängigkeiten müssen injiziert werden. Es ist einfach:
%Vor%Aber was, wenn ich möchte, dass meine Foo-Klasse in der Lage ist, Bars zu erstellen, ohne die genaue Implementierung hinter IBar zu kennen? Ich kann hier an 4 Lösungen denken, aber alle scheinen Nachteile zu haben:
Letzter Fall scheint natürlich, aber BarCreator-Klasse hat zu wenig Code. Also wie denkst du, welches ist das Beste?
Dafür wurden Fabriken geschaffen.
Wenn Sie der Meinung sind, dass Ihre Fabrik zu wenig Code hat, fragen Sie sich, welchen Nutzen Sie daraus ziehen, wenn Sie die Instanz nur inline erstellen. Wenn die Vorteile die Kosten des hinzugefügten Codes übersteigen, machen Sie sich keine Sorgen.
Ich würde den Service-Standort persönlich meiden, oder wenn Sie ihn wirklich benutzen müssen, würde ich ihn sowieso hinter einer Fabrik verstecken. Der Servicestandort kann leicht missbraucht werden und dazu führen, dass der Container in Code eindringt, mit dem er nichts zu tun haben sollte.
Aus praktischen Gründen können Sie in einigen Containern eine Factory angeben, die vom Container verwendet wird, wenn eine Instanz einer Komponente erstellt wird. In diesem Fall könnte Ihre Klasse direkt von IBar abhängen, aber Ihr Container würde IBarCreator aufrufen, wenn eine neue Instanz benötigt wird. Castle Windsor hat zum Beispiel die Methoden UseFactory und UseFactoryMethod in ihrer API.
Wenn Sie ein Problem mit der redundanten Factory-Schnittstelle haben, können Sie hier zwei Vorgehensweisen wählen.
Machen Sie es mit Generics wiederverwendbar:
%Vor%Oder verwenden Sie die anonyme Funktion als Factory:
%Vor%Ich fühle, wenn du sagst "Ich möchte, dass meine Foo-Klasse in der Lage ist, Bars zu erschaffen", kommt eine weitere Regel, die "Trennung von Sorgen" ist. Sie sollten also die Aufgabe der Klassenerstellung an etwas anderes delegieren und Foo sollte sich keine Sorgen um diese Aufgabe machen.
Tags und Links c# dependency-injection solid-principles