Wir verwenden ein "State Framework" (basierend auf dem State Pattern), das seinen aktuellen Zustand nicht offen legt, was manchmal bedeutet, dass ich Dinge auf Umwegen tun muss.
Als ich diese Design-Entscheidung in Frage stellte, war eine der folgenden Begründungen: "Wenn Sie den aktuellen Status kennen müssen, verwenden Sie ihn falsch".
Stimmt das? Ich bin kein großer Experte für State-Machines.
(Ich frage hier, weil ich weiß, dass ich eine inhärente Verzerrung gegen das Zustandsmuster habe, was ich zu ausführlich finde.)
BEISPIEL
Stellen Sie sich ein System vor, das in einem der Zustände zwei Sensoren liest. Ein Sensor gibt einen numerischen Wert, der andere einen booleschen Wert, der angibt, ob der erste "zuverlässig" ist oder nicht. Das System gibt einen Wert aus, der entweder der aktuelle "gute" Wert oder eine Interpolation (oder eine andere ausgefallene Berechnung) basierend auf den letzten n guten Werten ist.Meine Idee wäre, zwei Unterzustände zu haben - das eine "gut", das andere "nicht". Und wenn ein neuer Wert eintrifft, möchte ich die Zustandsmaschine fragen, in welchem Zustand sie ist, damit ich weiß, wie man mit der Interpolation umgeht.
(Ich denke, ich habe meine eigene Frage beantwortet: Die Lösung wäre, ein NewDataValue(val) -Ereignis in der Zustandsmaschine zu haben, das würde den Wert nur vom 'guten' Zustand weiterleiten?)
Ich muss der Person zustimmen, die den Kommentar "Unrecht verwenden" gemacht hat.
Der springende Punkt einer Zustandsmaschine ist eine Blackbox, in die Ereignisse gepumpt werden und die basierend auf diesen Ereignissen bestimmte Dinge passieren lassen (einschließlich Zustandsübergängen). Die Ereignisse selbst sollten nicht vom aktuellen Zustand der Maschine abhängen.
Ich kann mir keine einzige Situation vorstellen, in der sich das -Ereignis je nach dem aktuellen Zustand ändern sollte (aber zögern Sie nicht, mich aufzuklären, wenn Sie eines haben).
Ein Ereignis wird immer sein, was es ist. Wenn es basierend auf dem aktuellen Status anders behandelt werden muss, ist das ein Problem für die Zustandsmaschine selbst, nicht das Ereignis pump.
Tatsächlich ist die ganze Idee, ein Ereignis basierend auf dem aktuellen Zustand zu ändern, der Kapselung geschuldet.
Die besten State-Maschinen haben eine sehr einfache Form:
%Vor%Mit anderen Worten, Ereignisse werden irgendwie hineingepumpt (unabhängig vom Zustand) und es hat bestimmte Effekte, die auf seinem Zustand und den Ereignissen beruhen. Und es behält seinen eigenen Zustand.
In Bezug auf die Aktualisierung Ihrer Frage, wo Sie die Ausgabe anders handhaben möchten, je nachdem, ob die letzte Lesung gut war oder eine Formel, die auf vorherigen basiert, würde ich das einfach in den Effektbereich legen. Lassen Sie die Zustandsmaschine den aktuellen Wert plus ausgeben, um anzuzeigen, ob sie vom Sensor stammt oder berechnet wurde.
Dann kann Ihr Code, der die Effekte behandelt, mit diesen Informationen tun, was er will. Das gibt Ihnen effektiv die Informationen, die Sie brauchen, und bricht nicht die Black-Box-Natur.
Nun, das ist die wirkliche Frage. Warum müssen Sie den aktuellen Status der Zustandsmaschine kennen? Was hast du vor damit zu tun?
Wenn Sie es sich überlegen, versucht das auf der Grundlage des aktuellen Status und neuer Eingaben vorherzusagen, wo sich die Zustandsmaschine in Zukunft befinden wird, dann führen Sie etwas parallel zur Zustandsmaschine aus. Keine Ahnung, ob das gut oder schlecht ist, hängt davon ab, was und warum du es tust.
Offensichtlich ist die Zustandsmaschine eine Blackbox (oder in manchen Fällen scheint es wie ein Spielautomat!), in die Sie Daten einspeisen und aus denen Sie Daten entnehmen können.
Wie bei der Programmierung müssen die Dinge keine undurchsichtigen schwarzen Kästchen sein. Die Dinge können immer klar umrahmte Boxen sein, die Eingabeschlitze und Ausgabeschlitze haben, aber Sie können zumindest die Gänge sehen, die in ihnen laufen. Aber es widerspricht der Abstraktion, wenn Sie versuchen, es zu umgehen, da die Zustandsmaschine einen Logikblock kapseln soll.
Also, die Deckkraft der Struktur ist nicht wirklich das Problem, es ist das, was Sie mit der Information machen wollen, ob oder wann Sie es bekommen.
"Wenn Sie den aktuellen Status wissen müssen, verwenden Sie ihn falsch". - Das ist richtig.
Der aktuelle Status kann nicht angezeigt werden. All die Dinge, die dich dazu zwingen, anders zu handeln, weil du dich in einem bestimmten Zustand befindest, sollten innerhalb ( und nur dort ) dieses Staates platziert werden - als private Methoden, die von öffentlichen oder öffentlichen aufgerufen werden nichts (oder etwas anderes) in anderen Staaten. Deine "Staatsmaschine" muss funktionieren ... und du, von draußen kommend, solltest nicht wissen warum.
Im hierarchischen Systemdesign kennt normalerweise das Objekt der höheren Ebene nur die Abstraktion des Zustands des Objekts der unteren Ebene, z. state_good abstrahieren (perfekt, akzeptabel, ...) und state_bad abstrahieren (failed1, failed2, failed3 ..).
In nicht-hierarchischen Systemen ist es in Ordnung, wenn ein Objekt den Zustand eines anderen Objekts genau kennt, insbesondere wenn Objekten ungleiche Aufgaben zugewiesen sind.
Janusz
Tags und Links design-patterns state-machines