Vielen Dank an alle für die rege Beteiligung!
Das hilft mir "in alle Richtungen zu ermitteln"
und ich will Euch ein wenig von den bisherigen Ergebnissen meiner Suche berichten.
Leider ist es bisher entweder nicht der passende Ansatz für mein Problem (nämlich den Programm-Status übersichtlich zu verwalten) gewesen, oder es übersteigt etwas meine Fähigkeiten (sonst hätte ich das ganze Problem ja wahrscheinlich auch garnicht).
Den Ansatz von "Der schöne Günther" hab´ ich ausprobiert und hab´ mich irgendwie in einem (selbstgemachten) Wirrwar zwischen Listener und Sender sowie Status, Event und Message verheddert.
Das war dann für mich nicht nur unübersichtlich, sondern hat, nicht zuletzt genau deshalb, auch schlicht nicht funktioniert.
Ich finde dieser Beitrag:
https://softwareengineering.stackexc...status-updates
beschreibt auch nochmal sehr schön die Problemstellung.
Zumal, dem Beispiel mit dem Automaten folgend, die Ausgabe eines Artikels dazu führen kann, daß der Automat leer ist!
Irgendwie hänge ich im Moment zwischen den theoretischen Ansätzen und der praktischen Umsetzung.
Ich habe dazu mal eine kleine StatusDemo, siehe Anhang, erstellt.
In der Demo geht´s darum bestimmte Events (Spritztour, Urlaub, Arbeiten, Lotto, Tanken) in Abhängigkeit des Status (Portemonnaiebetrag, Tankinhalt) zu ermöglichen oder zu verbieten. D.h. der Status beeinflußt die Events!
Nun beeinflussen aber die Events auch den Status (beim Lotto sogar in zufälliger Weise). Es gibt also eine gegenseitige Abhängigkeit zwischen Status und Events!
Genau hier fängt für mich das Durcheinander an! 
Bitte nicht falsch verstehen: Es geht in der Demo nicht darum, wie ich vermeiden kann, daß ich nicht mehr zur Tankstelle fahren kann, wenn der Tank leer ist!
Die Demo dient vielmehr dem Zweck:
1. die Problemstellung in kleinem Rahmen praktisch darzustellen
2. eine konkrete Anwendung zu haben an der ich eine Lösung ausprobieren kann.
Im Moment versuche ich also in der StatusDemo#1 sowas wie eine Status-
Unit zu implementieren, die das Hauptprogramm von dem ganzen if-or-then-else-Spaghetti
entlastet und den Status schön übersichtlich und wartbar darstellt. Ein erster Erfolg war ja schon mal, daß ich die Event-Buttons enable, wenn es der Status zulässt und damit schon mal die Events entlastet habe.
Aber damit greife ich von einem niedrigeren Level auf ein höheres Level zu (nämlich daß ich in SetStatus auf die Buttons zugreife), was mir dann auch nicht so wirklich gefällt.
Nebenbei bemerkt: In der Demo wird der Status dadurch behandelt, indem jedes Event zu Begin ein GetStatus und am Ende ein SetStatus ausführt.
Wenn ich nicht wüßte, daß in Delphi eigentlich ALLES geht, dann würde ich mir langsam die Frage stellen, ob das überhaupt geht, was ich mir da vorstelle und ich den Spaghetti-Code so nehmen muß, wie er eben entsteht - schließlich funktioniert´s ja so auch.
Oder hänge ich vielleicht an einem viel grundlegenderen Verständnis der Dinge fest?
Deshalb noch was Grundsätzliches zum "Status" als solchem:
Üblicherweise findet man in Statemachines Statusnamen, wie z.B. "File_eingelesen". Das ist zwar verständlich, aber
IMHO für den Code nicht sonderlich hilfreich. In der Demo hab´ ich deshalb versuchsweise folgende Definition von "Status" verwendet:
>Ein Status wird durch eine oder mehrere Variablen (sog. Status- oder Zustandsvariablen) beschrieben<
Ein Status wird also nicht durch ein Event beschrieben! Insofern ist "Spritztour_gemacht" kein Status und sowas wie "File_eingelesen" wäre auch kein Status. Ich will mich jetzt nicht an dieser Definition festbeißen, denn schließlich könnte man "File_eingelesen" einfach mit einer boolschen Variable beschreiben.
Oder gibt es aus Eurer Sicht eine sinnvollere Definition für "Status", die man dann auch straight in Code umsetzen kann?
Vielleicht sowas ähnliches wie:
>Ein Status ist ein Object mit Attributen, die den Status beschreiben<
I still try and still cry ...
Martin