Hallo Zusammen,
folg. Situation:
In einer Anwendung benötige ich einen Dateiloader. Dieser soll vorerst CSV-Dateien laden. Später soll das ganze über Excel (*.xls) laufen. Sprich ich möchte den Loader event. mittels DI austauschbar gestalten.
Die Injection kann so ablaufen:
public class MainWindow
ctor(IDateiLoader) ...
Jetzt zu meinem Problem:
Der Dateiloader müsste beim CSV-Loader Infos enthalten, wie z.B. Trennzeichen (Semikolon, Komma, ...). Bei Excel sind event. wieder andere Infos für den Loader wichtig. Normalerweise wäre hier der ideale Weg, dass im Window bei CSV das Trennzeichen ausgewählt werden kann. Der Loader müsste dann IM WINDOW instanziiert werden. Als Konstruktorparameter wäre dann beim CSV-Loader das Trennzeichen mit anzugeben.
Mit DI funktioniert dies nicht, da die Instanziierung des Loaders ja bereits vor Erstellung des Windows erfolgt. Ungünstig, da hier ggfs. noch nicht bekannst ist, mit welchem Trennzeichen gearbeitet werden soll. Die Instanziierung im Window ist ungünstig, da ich ja dann eine feste Abhängigkeit zu der Lib habe, wo sich der Loader befindet.
Mir geht es in diesem Thread nicht speziell um dieses Loader-Beispiel, sondern einfach um die Thematik, wie ich mich verhalten soll, wenn im Konstruktor Parameter gefordert werden, die erst zur Laufzeit bekannt sind. Dies natürlich unter dem Gesichtspunkt der bestmöglichen Entkopplung. Ich bin zumindest der Meinung, dass bei einem austauschbaren Dateiloader, individuelle Parameter eines bestimmten Loaders in den Konstruktor gehören. Sollte hier jemand eine bessere Lösung haben, wäre ich für Infos sehr dankbar.
Eine Idee ist noch, in das Window eine virtuelle Factory Methode zu integrieren, die mir den Loader erstellt. So kann schnell eine Ableitung mit einem anderen Loader erstellt werden, ohne dabei den bestehenden Code anfassen zu müssen.
Mich würden hier mal Eure Meinungen interessieren, da ich immer wieder unschlüssig bin, wie ich mit diesem Problem umgehe. Zumindest stelle ich auch auf Grund meines o.g. Problems zur Zeit immer mehr diesen "Dependency-Injection-Wahn" in Frage.