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

[mh18058]

Hallo zusammen,
vielleicht weiß jemand eine Antwort auf die Frage: "Gibt es ein Design-Pattern für den Programm-Status?"
bzw. "Wie behandelt man den Programm-Status in Delphi ordentlich und übersichtlich?" :?:

Ich versuche mal ein einfaches Szenario zu beschreiben, woher meine Frage kommt: :-D
1. Ein Programm mit Benutzeroberfläche, startet zunächst mit allen Eingabeelementen zur Weiterverarbeitung auf disabled.
Dieser Status wird durch die globale Variable Inputdata_ok := false; beschrieben.
2. Das Programm liest nun ein Inputfile ein.
3. Wenn das gelingt, wird dieser Status durch Inputdata_ok := true; beschrieben.
4. Weil Inputdata_ok := true; ist, werden dann auf der Benutzeroberfläche die Eingabeelemente zur Weiterverarbeitung enabled.
5. Wenn das Einlesen eines neuen Files misslingt, wird zunächst wieder Inputdata_ok := false; gesetzt.
6. Weil nun Inputdata_ok := false; gesetzt ist, werden die Eingabeelemente disabeled.

D.h. die globale Statusvariable Inputdata_ok wird an vielen Stellen im Programm gesetzt und ausgewertet und
steuert mehrere Elemente gleichzeitig auf enabled bzw. disabled. Dieser Satz allein ist schon grauselig! :oops:

Bei einem umfangreichen Projekt kam ich dann mit den vielen Stati auch ziemlich durcheinander. :roll:
Folglich stellte sich die Frage, ob es da vielleicht ein Architekturmuster, ein Design-Pattern,
eine Komponente o.ä. gibt, was den Status eines Programms übersichtlich behandelt.
Vielleicht hat ja jemand auch einfach eine passende Programmierregel für mich, damit ich mit den Stati besser klarkomme. :idea:
Vielleicht hab´ ich auch ganz grundsätzlich einen falschen Ansatz. :stupid:

Ich hoffe Ihr kennt, bzw. versteht das Problem und könnt mir einen Tip geben wie ihr damit umgeht. :thumb:
Gruß
Martin

[freimatz]

Hoi Martin,
ich denke nicht, dass es da ein Design-Pattern gibt. Das ist eher ein Antipattern.
Globale Variablen sind per see schlecht. In meinem Home-Projekt habe ich leider auch solche. :oops:

Bei uns in der Firma haben wir für den Status ein Object das man sich von einer Factory holen kann. Und diese Factory wird dann üblicherweise über Dependency Injection den Verwendern reingereicht.

[Rollo62]

StateMachine ?

https://www.delphipraxis.net/186504-...er-delphi.html
https://github.com/SirRufo/stateless

Ich würde aber auch meinen dass dies mit Kanonen auf Spatzen ist, ich denke dafür ist dein State zu simpel ist,
und durch eine spezielle Klasse oder Singleton dafür abgebildet werden könnte.
Ich habe aber nicht ganz nachvollzogen was genau Du gerne Alles hättest.

Womöglich kommt sogar irgendwas mit Publish/Subscribe in Frage, was dann deine einzelnen Module benachrichtigt und verwaltet.

(Kanonenboote auf eine ganze Spatzenherde) :stupid:

[mh18058]

Hallo,
vielen Dank für eure schnellen Antworten.

@Rollo62
Ich hätte gerne den Durchblick! :lol:
Spaß beseite:
Mein Erklärbeispiel war vielleicht zu einfach. In Wirklichkeit ist es sehr umfangreich geworden mit vielen peinlichen Zugriffen auf die Statusvariablen. :oops:
Der Status ist ja ein globaler Zustand auf den ich überall, also auch lokal, reagiere.
Und da hab´ ich beim letzten Projekt einfach den Überblick verloren, was da wann wie wo gesetzt und ausgewertet wird. :roll:

Vielleicht war meine Frage nach Design-Pattern auch ungeschickt gestellt, weil ich zur Laufzeit garkeine neuen Objekte erzeuge.
Vielmehr ist es die Frage nach einer strukturierten Ordnung in Sachen Status.
Ich habe den Verdacht, daß ich die Komplexität beim Status anfänglich einfach unterschätzt habe und dadurch so schleichend Schludercode entstanden ist.

Ja, Statemaschine hatte ich aufgemalt und daraus immerhin die einzelnen Stati hergeleitet. Das war ja schon mal was! :P
Soweit ich das im Moment beurteilen kann, ist "Stateless" von SirRufo ein Gerüst an das man seine Programmfeatures dranhängen kann.
Klar, in meinem Fall sicher mit Kanonen auf Spatzen geschossen, aber wenn ich damit dann immer genau weiß in welchem Status das Programm ist, soll´s mir recht sein. :)
Das nächstes Delphi-Projekt ist ein UserInterface für einen Fortran-Numbercruncher. Da könnte "Stateless" ein geeigneter Weg sein.
Ich werde mir das mal genauer ansehen und dann nochmal in mich gehen ... das Thema ist noch nicht erledigt ... :?

Danke euch auf jeden Fall für eure prompte Hilfe.
Gruß
Martin

[hoika]

Hallo,
wenn es unbedingt ein Pattern sein soll:
Singleton

1 einzelnes Objekt mit je einem Property je Status,
dazu Get- und Set-Methoden.

Um rauszufinden, wo ein Status gesetzt wird,
reicht dann ein Breakpoint auf die Set-Methode.

[Der schöne Günther]

Das ist doch eigentlich überhaupt nicht Ungewöhnliches. Außer dass ich nicht verstehe, wo auf einmal globale Variablen notwendig geworden sind.

Bau dir doch erst einmal ein einfaches Objekt das den Zustand regelt. Werde dir über die Zustände (

Delphi-Quellcode:

TEingabeZustand = (warteAufErsteEingabe, eingabeFalsch, datenWerdenVerarbeitet, ...)

) klar und setze die Zustandsübergänge um (

Delphi-Quellcode:

.eingabeWarRichtig()

,

Delphi-Quellcode:

eingabeWarFalsch()

, ...).

Wenn das alles stimmt fehlt doch nur noch, dass deine Oberfläche (TForm/TFrame) die Änderung des Zustands mitbekommt und entsprechend darauf reagiert. Heißt: Dein Formular muss dein eben gebasteltes Zustands-Objekt kennen, und nicht dein Zustands-Objekt deine Formulare.

Wie man auf Änderungen reagiert ist im Endeffekt genauso wie ein

Delphi-Quellcode:

OnClick

bei einem

Delphi-Quellcode:

TButton

, dein Zustandsobjekt bietet ein Event an, und deine Oberfläche hängt sich an das Event dran. Wie man das konkret umsetzt gibt es viele Möglichkeiten, aber über "Publish / Subscribe" sollte man zu dem Zeitpunkt schonmal etwas gelesen haben.

[kretabiker]

Observer-Pattern in Verbindung mit einem Singleton für den Status?

[Der schöne Günther]

Was habt ihr dauernd mit euren Singletons?

Warum sollte man z.B. nicht eines Tages mehrere Tabs haben wo man mehrere dieser Bearbeitungsvorgänge gleichzeitig machen kann? Tut doch keinem weh...

[mh18058]

Hallo,
wow :o an der Diskussion sehe ich, daß meine Frage vielleicht doch nicht so "aus der Welt" war. :lol:

Singleton für ein Statusobjekt macht für mich schon Sinn! Schließlich gibt´s immer nur einen Status für einen Zustand. Das ist Fakt.
Allerdings macht der Aufwand für ein Singleton nur Sinn, wenn zur Laufzeit neue Stati hinzukommen und man mit dem Singleton verhindern will, daß ein Status zweimal existiert. Das kann bei einer späteren Verwendung des Statusobjekts aber durchaus vorkommen. Mit Singleton wäre es also zukunftssicher.

Zitat:

Zitat von Der schöne Günther (Beitrag 1496373)

Das ist doch eigentlich überhaupt nicht Ungewöhnliches. Außer dass ich nicht verstehe, wo auf einmal globale Variablen notwendig geworden sind.

Bau dir doch erst einmal ein einfaches Objekt das den Zustand regelt. Werde dir über die Zustände (

Delphi-Quellcode:

TEingabeZustand = (warteAufErsteEingabe, eingabeFalsch, datenWerdenVerarbeitet, ...)

) klar und setze die Zustandsübergänge um (

Delphi-Quellcode:

.eingabeWarRichtig()

,

Delphi-Quellcode:

eingabeWarFalsch()

, ...).

Wenn das alles stimmt fehlt doch nur noch, dass deine Oberfläche (TForm/TFrame) die Änderung des Zustands mitbekommt und entsprechend darauf reagiert. Heißt: Dein Formular muss dein eben gebasteltes Zustands-Objekt kennen, und nicht dein Zustands-Objekt deine Formulare.

Wie man auf Änderungen reagiert ist im Endeffekt genauso wie ein

Delphi-Quellcode:

OnClick

bei einem

Delphi-Quellcode:

TButton

, dein Zustandsobjekt bietet ein Event an, und deine Oberfläche hängt sich an das Event dran. Wie man das konkret umsetzt gibt es viele Möglichkeiten, aber über "Publish / Subscribe" sollte man zu dem Zeitpunkt schonmal etwas gelesen haben.

Ich denke da liegt für mich der Schlüssel dafür den Status übersichtlich in den Griff zu bekommen. Danke an "Der schöne Günther"! :o

Habe inzwischen erneut recherchiert und folgendes Interessantes gefunden (komisch, warum erst jetzt?): :)
https://sourcemaking.com/design_patterns/state
https://sourcemaking.com/design_patterns/state/delphi
Source: http://sourcemaking.com/files/sm/CsvParser.pas

Ich stecke zwar noch im Tunnel, aber im Tunnel gibt´s nur noch zwei Richtungen: vorwärts oder zurück! Also vorwärts ... :-D
Grüße
Martin :thumb:

[Stevie]

Zitat:

Zitat von kretabiker (Beitrag 1496381)

Observer-Pattern

Genau das - anstatt von überall den global state auszulesen und vermutlich Code zu verstreuen, der nach dem Ändern dessen entsprechende Aktualisierungen anstößt gibt in diesem Fall die Import-Komponente die Möglichkeit, sich über Ereignisse (Import erfolgreich/fehlgeschlagen) benachrichtigen zu lassen und dann entsprechend zu reagieren.

Und Events sollten einem Delphientwickler ja nicht neu sein - denn genau das ist im Kern das Observer-Pattern. Einer sagt, dass was passiert ist und ein anderer reagiert darauf.

[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 :-D

[Stevie]

Die meisten wissen nicht, worum es eigentlich geht und wiederholen nur, was sie mal irgendwo gehört haben.

Das Problem bei global state (egal, ob einzelne globale Variablen oder ein fest verdrahtetes Singleton) ist, dass man eher schwerlich entkoppelt testen kann. Wenn Komponente/Klasse/Funktion X hartverdrahtet Y.Irgendwas referenziert, dann muss ich in einem Test immer dafür sorgen, dass Y.Irgendwas auch den richtigen wert für den Testvorgang enthält. Misko Hevery erklärt in seinem Guide recht gut, warum sich daraus Probleme ergeben, sowohl technischer Natur als auch vom Verständnis her, wenn man sich die API von X anschaut, welche möglicherweise nix über ihre "geheime" Interaktion mit Y sagt.

Zudem macht er einen Unterschied zwischen "Singleton" und der "singletoness" - beim Singleton, wie oft implementiert (je nach Sprache mehr oder minder einfach zu realisieren) geht es darum, komplett zu verhindern, dass jemand jemals eine andere Instanz als die einzig wahre erstellen kann (technische Limitierung). Bei der "singletoness" geht es darum, dass es von der Semantik der Anwendung nur eine Instanz gibt. Es steht aber nicht im Weg, zum Testen selbst eine Instanz davon zu erzeugen, um sie für den Test mit entsprechenden Daten zu versorgen, etc oder gar auszumocken.

Am Beispiel von TMessageManager erklärt: Wenn ich in meinem Code überall einfach TMessageManager.DefaultManager.SubscriptToMessage oder SendMessage aufrufe, dann habe ich mich an den Singleton gebunden. Nehme ich über den ctor oder eine Eigenschaft eine TMessageManager Instanz entgehen, mit der ich interagiere, dann habe ich diese Abhängigkeit entfernt bzw "aufgeweicht", denn ich kann von außen steuern, mit welcher TMessageManager Instanz die Komponente kommuniziert.

[Elrond]

Für das gleiche Problem verwende ich das Observer-Pattern. Es endet ja nicht mit nur einen Status, es gibt ja viele solche Status auf die ein Programm reagieren muss, mit DB erfolgreich verbunden, neues Objekt zum bearbeitet ausgewählt (--> neue Sicht laden) usw.

Auch nutze ich gerne die Delphi Actions um Bedienelemente zu steuern. Die (Arbeits-)Klassen registrieren für ihre Aufgaben Aktionen und halten die hoheit darüber inwiefern diese Aktionen zulässig sind. Gibt es z.B. keine Datenbankverbindung, kann ich meine Änderung nicht speichern und die Aktion ist disabled und entsprechend alle mit ihr verknüpften Bedienelemente. Gleichzeitig beobachte ich den Status der Datenbankverbindung und reagiere entsprechend.

[Rollo62]

Zitat:

Zitat von Stevie (Beitrag 1496430)

Zudem macht er einen Unterschied zwischen "Singleton" und der "singletoness"

Sehr schön, das gefällt mir, den kannte ich noch nicht.
Das lässt sich ja auch wunderbar gendern, das muss ich mir unbedingt merken: Singleton*ness :-D

Zitat:

Zitat von Stevie (Beitrag 1496430)

Nehme ich über den ctor oder eine Eigenschaft eine TMessageManager Instanz entgehen, mit der ich interagiere, dann habe ich diese Abhängigkeit entfernt bzw "aufgeweicht", denn ich kann von außen steuern, mit welcher TMessageManager Instanz die Komponente kommuniziert.

Richtig, dann sind wir wieder bei DI, es passt eben doch Alles irgendwie zusammen.

[mh18058]

Vielen Dank an alle für die rege Beteiligung! :thumb:

Das hilft mir "in alle Richtungen zu ermitteln" :) und ich will Euch ein wenig von den bisherigen Ergebnissen meiner Suche berichten. :-D
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). :oops:
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. :roll: Das war dann für mich nicht nur unübersichtlich, sondern hat, nicht zuletzt genau deshalb, auch schlicht nicht funktioniert. :cry:

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. :roll:
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! :shock:
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! :wink:
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 :roteyes: 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? :roll:

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< :gruebel:

I still try and still cry ... :cry:
Martin

[Sequitar]

Wäre vielleicht eine message loop, post/send message etwas passendes?
(deleted. Siehe post rollo62, zu spät gesehen )

[Uwe Raabe]

Vielleicht ist das Beispiel ja auch zu einfach oder ich habe dein eigentliches Problem noch nicht verstanden, aber ich würde die Buttons über Actions verknüpfen und die Werte über eine Message aktualisieren lassen.

Das angehängte Projekt zeigt wie man sowas prinzipiell entkoppeln kann.

[mh18058]

Hallo,

Zitat:

Zitat von Uwe Raabe (Beitrag 1496839)

Vielleicht ist das Beispiel ja auch zu einfach oder ich habe dein eigentliches Problem noch nicht verstanden, aber ich würde die Buttons über Actions verknüpfen und die Werte über eine Message aktualisieren lassen.

Das angehängte Projekt zeigt wie man sowas prinzipiell entkoppeln kann.

ja was ist DAS denn? Ich bin total geflasht! :shock: Ich hab´ wirklich nicht erwartet, daß sich ein Profi hinsetzt, das programmiert und dann innerhalb von 3 Stunden(!) DIE Lösung postet.
@Uwe: Absoluter Respekt - das sieht perfekt aus! Danke, danke, danke! :thumb:

Wenn man übrigens StatusDemo#1 mit StatusDemo#2 vergleicht, dann hat man ein tolles Lehrstück für prozedurale vs. objektorientierte Programmierung! :lol:
Es zeigt auch sehr schön, daß objektorientiert ggü. prozedural erstmal mehr Aufwand an Struktur und Zeilen bedeutet, sich hintenraus aber in der Wartbarkeit auszahlt.


Bevor Uwe gepostet hat, hab´ ich gestern natürlich noch weitergebrockelt:
In https://www.philipphauer.de/study/se...tern/state.php
beschreibt Philipp Hauer sehr verständlich das "State-Design-Pattern" (Warum hab´ ich das die ganze Zeit nicht gefunden? Google dachte wohl, daß mich das nicht wirklich interessieren kann!) und schreibt:

"Versetzen wir uns gedanklich in die 1970er Jahre: zur Blütezeit der Strukturierten Programmierung. Wie hätte man damals das Problem gelöst? Der aktuelle Zustand würde durch eine
Integer-Variable repräsentiert werden. 0 steht für Neutral, 1 für Bockig und 2 für Fröhlich. In jeder Operation (unterhalten(), kussGeben(), verärgern()) wird zunächst geprüft,
welchen Wert diese Integer-Variable hat und entsprechend wird ein Verhalten ausgeführt."

Da wurde mir auf einmal schon klar, wie sehr ich doch in der Denke des prozeduralen Programmierens verhaftet bin. :roll:

Ich habe dann mal versucht in meiner StatusDemo das State-Design-Pattern umzusetzen. Aber wohl nicht zuletzt aufgrund meiner Definition von "Status" ´n Knoten in´s Hirn gekriegt. :oops:
An der Stelle wurde mir dann klar, daß meine Problemstellung mit Statusbehandlung vielleicht nicht wirklich viel zu tun hat, sondern vielmehr mit gegenseitigen Abhängigkeiten.

@Uwe: Du hast das erkannt und einfach nur entkoppelt. Phantastisch! Danke Dir nochmals. :thumb:


Damit ist mein Problem gelöst. Bleibt nur noch die Frage nach einer praktikablen Definition von "Status":gruebel: , wenngleich die Frage jetzt nicht mehr so dringlich ist.

Gestern stand ich noch vor dem Abgrund - heute bin ich einen Schritt weiter! :wink:
Gruß
Martin

[Rollo62]

Zitat:

Zitat von Uwe Raabe (Beitrag 1496839)

Das angehängte Projekt zeigt wie man sowas prinzipiell entkoppeln kann.

Hallo Uwe,
ja mit Messages, das finde ich immer gut.

Allerdings habe ich meine Bedenken bei Actions die über Module hinaus benutzt werden.

Delphi-Quellcode:

object ButtonSpritztour: TButton
    ...
    Action = dmStatus.actSpritztour
    ...
  end

Ich hatte in der Vergangenheit öfters Fälle wo sich die IDE irgendwie verhaspelt hat,
und diese Links unbedingt wieder löschen wollte.
Ich meine es hängt damit zusammen welche Module gerade im Editor geöffnet sind, so dass der Designer die "sehen" kann.

Deshalb würde ich diese Links immer per Runtime setzen, damit die Zuordnung nicht zufällig mal verloren geht, wenn man auf den falschen Knopf drückt.