Im Grunde mußt du zur Beantwortung dieser Frage eine Kosten-Nutzen-Rechnung anstellen. Das per Singleton / Klassenvariablen / globalen Variablen zu lösen, ist zunächst einmal mit vergleichsweise wenig Aufwand verbunden. Der Preis dafür kommt in zweierlei Gestalt:midan23 hat geschrieben:
Die interessante Frage wäre:
Ist für ein zentrale Programmkonfiguration ein Singleton/Borg vertretbar oder sollte man sich nach einer anderen Lösung (wie zB die Konfiguration beim Anlegen neuer Objekte mit auf den Weg geben) umsehen ?
1) Die Nachvollziehbarkeit des Programmflusses leidet, weil hier Informationen an den eigentlichen Schnittstellen vorbeifließen.
2) Vor allem aber handelst du dir unter Umständen Probleme mit Nebeneffekten ein: Gerade wenn Nebenläufigkeit ins Spiel kommt (z.B. durch GUIs) kann es passieren, daß sich der Inhalt einer Konfigurationsoption ändert, ohne daß eine Funktion, die diese Optionen verwendet, etwas davon mitbekommt. Du müßtest also Locks / Semaphoren implementieren, und da wirds dann schon wieder reichlich kompliziert. Oder halt den Schreibzugriff untersagen. Ganz häßlich wirds beim (automatisierten) Testen: Du mußt vor jedem einzelnen Test sicherstellen, daß die Konfiguration genau die Werte enthält, von denen du ausgehst. Vergisst du das, und es gibt auch nur einen anderen Test, der an der Konfiguration etwas verändert, mußt du dich auf sehr seltsame Effekte einstellen. Dazu gehören Tests, die scheinbar völlig irrational mal durchlaufen und mal fehlschlagen, obwohl du am Code nichts veränderst.
Ich würde sagen: Für Code, der nur mal schnell hingeworfen wird, nicht kritisch (im Sinne von finanziellen, gesundheitlichen oder sonstigen Schäden) ist und den du nicht aus den Händen gibst, mag ein Singleton in Ordnung sein. Weil du als Urheber wissen solltest, wo die Gefahren lauern. Für alles andere solltest du den etwas "umständlicheren" aber solideren Weg einschlagen und Abhängigkeiten ausschließlich als Parameter übergeben.
