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

Bei einem umfangreichen Projekt kam ich dann mit den vielen Stati auch ziemlich durcheinander.
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.
Vielleicht hab´ ich auch ganz grundsätzlich einen falschen Ansatz.

Ich hoffe Ihr kennt, bzw. versteht das Problem und könnt mir einen Tip geben wie ihr damit umgeht.
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.

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)

[mh18058]

Hallo,
vielen Dank für eure schnellen Antworten.

@Rollo62
Ich hätte gerne den Durchblick!
Spaß beseite:
Mein Erklärbeispiel war vielleicht zu einfach. In Wirklichkeit ist es sehr umfangreich geworden mit vielen peinlichen Zugriffen auf die Statusvariablen.
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.

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!
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 (TEingabeZustand = (warteAufErsteEingabe, eingabeFalsch, datenWerdenVerarbeitet, ...) ) klar und setze die Zustandsübergänge um (.eingabeWarRichtig() , 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 OnClick bei einem 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 an der Diskussion sehe ich, daß meine Frage vielleicht doch nicht so "aus der Welt" war.

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 von 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 (TEingabeZustand = (warteAufErsteEingabe, eingabeFalsch, datenWerdenVerarbeitet, ...) ) klar und setze die Zustandsübergänge um (.eingabeWarRichtig() , 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 OnClick bei einem 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"!

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 ...
Grüße
Martin

[Stevie]

Zitat von kretabiker:

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.