nicht angemeldet
Statische Repositories hatte ich doch als die schlechtere Lösung bezeichnet, oder?
Stimmt, hast du. Ich hab mich in einer anderen Frage anders entschieden: Du hast ein Singelton-Interface vorgeschlagen. Singeltons und statische Methoden lösen ähnliche Probleme auf unterschiedliche Weise: In beiden Fällen möchte man vermeiden, dass Methoden auf unterschiedlichen Instanzen der Klasse aufgerufen werden. Mit einem Singelton-Interface stellt man sicher, dass zur Laufzeit nur eine einige Instanz der Klasse jemals erzeugt wird. Mit einer statischen Methode legt man zur Entwicklungszeit fest, dass eine Methode keinen Zugriff auf den Laufzeit-Kontext $this hat. Im Allgemeinen bevorzuge ich statische Verfahren, die Fehler frühzeitig aufdecken. Im konkreten Fall, halte ich es aber für möglich, dass ein Repository mit unterschiedlichen Datenbank-Verbindungen instanziiert wird, bspw. um Datenbestände zu synchronisieren, also habe ich mich gegen Singelton und statische Methoden entschieden.
Die DB Connection von der Repository-Factory in das Repository zu übergeben ist aus meiner Sicht die genau richtige Lösung.
Bzw. im 0815-Konstruktor. Mein Verhältnis zu Factorys (und anderen Erzeugungsmustern) ist ambivalent. Wenn ich eine Klasse habe, die so komplex ist, dass ich eine zweite Klasse brauche, nur um Instanzen der ersten Klasse zu erzeugen, dann ist das ein Indiz dafür, dass die erste Klasse zu viele Dinge erledigt. Mit einer Factory oder einem Builder lässt sich die Komplexität verwalten, aber nicht vermindern. Manchmal ist das aber auch "gut genug" oder sogar die beste Lösung.
Rolf B
Tabellenkalk