Gibt es ein Design-Pattern für den Programm-Status?

[Rollo62]

Möglich wäre auch TMessageManager, davon habe ich unzählige im Dauereinsatz.
Die Messages können wunderbar und ohne Probleme in alle Richtungen verteilt werden, wenn man etwas auf die Threadsicherheit achtet.
Damit läuft quasi mein ganzer App-Unterbau völlig problemlos, und entkoppelt die ganzen Module.

Aber die Diskussionen gegen Singleton verstehe ich auch nicht immer ganz.
Ich habe doch eine MainForm, da könnte ein Status drauf verwaltet werden, ist das nicht auch schon ein "Singleton" ?
Irgendwo muss doch am Ende der "Publisher" persistent sein, damit alle "Subscriber" von ihm informiert werden können.
Ist der "Publisher" dann nicht auch ein Singleton ?
Gerne arbeite ich auch mit Singleton-Klassen der Art "class procedure TDingi.Instance.MachWas; static;", mit einer class var als Instance,
ja das ist definitiv ein Singleton, na und ?

Ich verstehe ja das es GRUNDSÄTZLICH besser ist per Immutable und Messages zu kommunizieren,
aber am Ende muss doch irgendwer, irgendwo immer noch den "State" halten.
Nach meinem simplifiziertem Verständnis ist das doch dann immer ein "Singleton" im weitesten Sinne, und sei es die DB,
oder eine Fileressource, die geteilt werden muss.
Ich halte es z.B. da wo ich Initial den State konfiguriere, und dann an mehreren Stellen auslesen kann, und nur im UI Thread lebt, für durchaus tragbar,
wenn ein Messaging zu aufwendig wäre (Ok, das Faulheitsargument ).

Mein Fazit: Singleton möglichst vermeiden, aber es kann auch gute Gründe geben sowas zu verwenden.
Gundsätzliches Verteufeln ist auch eine schlechte Angewohnheit