3. Du hälst an allen stellen eine Referenz auf deinen ConfigManager oder wie er bei dir auch heißt.
Den könntest du bereits in der
DPR erzeugen und an das erste Form und andere Objekte, die dort erzeugt werden übergeben.
Wenn du Code nur in Forms liegen hast und/oder dein Hauptform in seinem ctor oder FormCreate deinen Initialisierungs-Code hat, dann könntest du es auch dort erzeugen.
Wichtig ist halt, dass du die Referenz an alle Objekte weitergibst, die du anlegst.
Globale Funktionen wären hier natürlich Shy-C, aber das sind sie sowieso.
Wenn du deine Logik, die mit den Config-Daten arbeiten musst schön in Instanzmethoden von Klassen stehen hast, kannst du diesen Klassen einfach eine Referenz mitgeben.
Globale Referenzen sind ziemlich beschissen, was Skalierung oder spätere Änderungen angeht.
Es kann ja gut sein, dass du einen 2. Satz von Configs haben willst, der während des Editierens "lebt" und wenn der User diesen 2. Satz testen will, will er ja nicht den richtigen Satz Configs zerlegen. Für alle Fenster/Worklflows, die nix mit dem Testen der neuen Config zu tun hätten, sollte ja weiterhin der richtige satz von Werten gelten können.
Oder wenn du einen Thread startest, willst du dem vllt eine kopie der aktuellen Settings mitgeben. So kann der seine Aufgabe erledigen ohne a) ständig alle Zugriffe auf die Config mit Criticalsections zu sperren (und gesperrt zu werden) und b) würde er konsistent mit dem gleichen Satz von Anfang bis Ende arbeiten.
Wenn du globale Variablen benutzt, kannst du sowas schlicht und ergreifend
vergessen.
@Datamodule: Die Viecher sind doch auch nur globale Variablen.
Rein vom Code design her, wären Datamodules höchsten zu gebrauchen um von der Configklasse instanziert zu werden damit dort einige Logik visuell zusammengeklickt werden kann. (Also 2-10 Minuten Code eingespart, dafür X Abhängigkeiten und Points of Failure gewonnen)
Aber unterm Strich bringen DMs fast gar nix.