Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Best Practice CW05
Hey,
mich würde interessieren, wir ihr mit der Erweiterung von PhotoManager und PhotoFactory umgegangen seid oder im idealen Fall umgehen würdet.
- Was im Kurs angesprochen wurde:
a) PhotoManager und PhotoFactory abstrakt zu machen.
b) die Felder instance auf die Instanzen der Implementierung zeigen Lassen
c) alle Verwendungen der Singletons in der Wahlzeitumgebung auf die domain spezifischen Implementierung von den Manager und Factory referenzieren.
zu a) Meiner Ansicht nach läuft das dann entweder auf b) hinaus oder fungiert als reines Template
zu b) störe ich mich auf ein statischen Zugriff auf getInstance von PhotoManager, aber was ich erhalte ist dann gar kein PhotoManager sonder irgendeine Implementierung. Die Instanz der Klassen ist ja dann nicht mehr verfügbar.
zu c) lässt zwar die Isntanzen von PhotoManager und PhotoFactory unberührt und können wiederverwendet werden, aber man hat ja gesehen, 30 referenzen im Code zu ändern, kann keine evolutionär standhafte Lösung sein
Ich störe mich im Allgemeinen so ziemlich an den “Singletons”, die z.T. nicht richtig implementiert sind und versuche, an Alternativen zu denken.
ich werfe mal was in den Raum und würde mich über eine Diskussion freuen:
- Eine Klasse, auf die zentral von der gesamten Wahlzeitumgebung zugegriffen wird und die instanzen der “singletons” hält, also insbesondere PhotoManager, Factory und was dann sonst noch so möglicherweise anfällt. Die Klasse kann man dann im StartUp Konfigurieren wie man es mag.
Ich sehe hier auch einige downsides, aber wie gesagt, mich würden eure Ansichten interessieren.
Was ist an den Singletons “z.T. nicht richtig” implementiert?
https://github.com/dirkriehle/wahlzeit/blob/master/src/main/java/org/wahlzeit/model/PhotoManager.java
Nach meinem wissen dürfte hier der constructor nicht public sein.
Abgesehen davon, was jetzt nicht falsch oder ungewöhnlich ist, unterscheidet sich die implementation zB. zur Photofactory. Da sich beide gleich verhalten, erhöht die Differenz, je nach Leser natürlich, nur die Einarbeitungszeit.
Wie stehen Sie denn zu dem Thema?
Ja, der Constructor waere besser protected oder private gesetzt gewesen.
Es gibt in Wahlzeit zwei (leicht) unterschiedliche Implementierungen von Singletons: Jene, die durch Unterklassenbildung erweiterbar sind, und jene, dies es nicht sind.
PhotoFactory war klar als erweiterbar gedacht; deswegen gibt es die setInstance Methode (ich habe uns ein weiteres Framework fuer Dependency Injection erspart, for better or worse).
Andere Singletons waren nicht dafuer gedacht, so zB PhotoCaseManager. Zu PhotoManager muss ich nochmal nachschauen, warum es nicht als erweiterbar gedacht/programmiert wurde.