🔢 🛫 👨🏻‍🔬 Wie man sich nicht mit einer Zustandsmaschine ins Bein schießt 🌛 🛣️ 🤷🏾

Die Zustandsmaschine wird von mobilen Entwicklern selten verwendet. Obwohl die Mehrheit die Prinzipien der Arbeit kennt und sie leicht unabhängig umsetzt. In diesem Artikel werden wir am Beispiel von iOS-Anwendungen herausfinden, welche Aufgaben von der Zustandsmaschine gelöst werden. Die Geschichte wird in der Natur angewendet und widmet sich den praktischen Aspekten der Arbeit.

Unter dem Schnitt finden Sie eine erweiterte Abschrift von Alexander Sychevs Rede ( Brain89 ) auf AppsConf , in der er seine Optionen für die Verwendung der Zustandsmaschine bei der Entwicklung von Nicht-Spiel-Anwendungen teilte.

Über den Redner: Alexander Sychev ist seit acht Jahren in der iOS-Entwicklung tätig. Während dieser Zeit war er an der Erstellung einfacher Anwendungen und komplexer Clients für soziale Netzwerke und den Finanzsektor beteiligt. Im Moment ist ein technischer Leiter bei der Sberbank.

Sie kommen aus vielen Bereichen zum Programmieren, haben unterschiedliche Hintergründe und Erfahrungen, daher erinnern wir uns zunächst an die grundlegende Theorie.

Erklärung des Problems

Eine Zustandsmaschine ist eine mathematische Abstraktion, die aus drei Hauptelementen besteht:

viele interne Zustände
die Menge der Eingangssignale, die den Übergang vom aktuellen Zustand zum nächsten bestimmen,
Sätze von Endzuständen, bei deren Übergang der Automat seine Arbeit beendet ("gibt das Eingabewort x zu").

Zustand

Mit Zustand meinen wir eine Variable oder eine Gruppe von Variablen, die das Verhalten eines Objekts bestimmen. In der Standard-iOS-Anwendung "Einstellungen " gibt es beispielsweise einen Punkt "Fett" ("Grundlegend → Universeller Zugriff"). Mit dem Wert dieses Elements können Sie zwischen zwei Optionen für die Anzeige von Text auf der Geräteanzeige wechseln.

Durch das Senden des gleichen Signals „Ändern Sie den Wert des Kippschalters “ erhalten wir eine andere Reaktion des Systems: entweder den üblichen Schriftstil oder Fettdruck - alles ist einfach. Wenn sich ein Objekt in verschiedenen Zuständen befindet und dasselbe Signal empfängt, reagiert es unterschiedlich auf eine Zustandsänderung.

Traditionelle Aufgaben

In der Praxis stoßen Programmierer häufig auf eine endliche Zustandsmaschine.

Spieleanwendungen

Dies ist das erste, was mir in den Sinn kommt - als Teil des Gameplays wird fast alles vom aktuellen Spielstatus bestimmt. Daher geht Apple davon aus, dass Zustandsautomaten hauptsächlich in Spieleanwendungen verwendet werden (wir werden dies später ausführlich erörtern).

Das Verhalten des Systems bei der Verarbeitung des gleichen Signals, jedoch mit einem anderen internen Zustand, kann anhand der folgenden Beispiele veranschaulicht werden. Zum Beispiel:

● Der Spielcharakter kann unterschiedliche Stärken haben: einer in mechanischer Rüstung und mit einer Laserpistole, der andere ist schwach gepumpt. Abhängig von diesem Zustand wird das Verhalten von Feinden bestimmt: Sie greifen entweder an oder rennen weg.

● Das Spiel wird angehalten. Der aktuelle Frame muss nicht gezeichnet werden. der Spieler im Menümodus oder im Spielprozess - das Rendern ist völlig anders.

Textanalyse

Eine der beliebtesten Textanalyse-Aufgaben im Zusammenhang mit der Verwendung einer Zustandsmaschine sind Spam-Filter. Es gebe eine Reihe von Stoppwörtern und eine Eingabesequenz. Sie müssen diese Sequenz entweder filtern oder gar nicht anzeigen.

Formal ist dies die Aufgabe, einen Teilstring in einem String zu finden. Um dies zu lösen, wird der Knut-Morris-Pratt-Algorithmus verwendet, dessen Softwareimplementierung eine Finite-State-Maschine ist. Der Status ist der Versatz der Eingabesequenz und die Anzahl der Zeichen im Musterstoppwort.

Bei der Analyse regulärer Ausdrücke werden häufig Finite-State-Maschinen verwendet.

Parallele Abfrageverarbeitung

Eine Zustandsmaschine ist eine der Optionen zum Implementieren der Anforderungsverarbeitung und zum Ausführen eines strengen Befehlssatzes.

Beispielsweise werden auf dem Nginx-Webserver Eingabeanforderungen verschiedener Protokolle unter Verwendung von Zustandsautomaten verarbeitet. Abhängig vom spezifischen Protokoll wird eine spezifische Implementierung der Zustandsmaschine ausgewählt und dementsprechend wird ein bekannter Satz von Anweisungen ausgeführt.

Im Allgemeinen werden zwei Klassen von Problemen erhalten:

Verwalten der Logik eines komplexen Objekts mit einem komplexen internen Zustand,
Bildung von Kontroll- und Datenflüssen (Beschreibung des Algorithmus).

Offensichtlich treten solche allgemeinen Aufgaben in der Praxis eines jeden Programmierers auf. Daher ist die Verwendung einer Zustandsmaschine möglich, auch in Nicht-Gaming-Inhaltsanwendungen, an denen die meisten mobilen Entwickler beteiligt sind.

Als Nächstes analysieren wir, wo und wann die Zustandsmaschine zum Erstellen typischer iOS-Anwendungen verwendet werden kann.

Die meisten mobilen Anwendungen haben eine mehrschichtige Architektur. Es gibt drei Basisschichten.

Präsentationsschicht.
Geschäftslogikschicht.
Eine Reihe von Helfern, Netzwerkclients usw. (Kernschicht).

Wie oben angegeben, steuert die Zustandsmaschine Objekte mit komplexem Verhalten, d.h. mit komplexem Zustand. Solche Objekte befinden sich definitiv in der Präsentationsschicht, da sie Entscheidungen treffen, indem Benutzereingaben oder Nachrichten vom Betriebssystem verarbeitet werden. Schauen wir uns die verschiedenen Ansätze für die Ausführung an.

In der klassischen Architekturmetapher von Model-View-Controller befindet sich der Status im Controller: Er entscheidet, was in der Ansicht angezeigt wird und wie auf Eingangssignale reagiert wird: Drücken einer Taste, Ändern des Schiebereglers usw. Es ist logisch, dass eine der Implementierungen der Steuerung eine Zustandsmaschine ist.

In VIPER befindet sich der Status im Präsentator: Er bestimmt den spezifischen Navigationsübergang vom aktuellen Bildschirm und der Anzeige von Daten in der Ansicht.

In Model-View-ViewModel befindet sich der Status im ViewModel. Unabhängig davon, ob wir reaktive Bindemittel haben oder nicht, wird das Verhalten des in der MVVM-Metapher definierten Moduls im ViewModel aufgezeichnet. Offensichtlich ist seine Implementierung durch eine Zustandsmaschine eine akzeptable Option.

Komplexe Objekte mit einem nicht trivialen Satz von Zuständen werden auch auf der Geschäftslogikschicht der Anwendung angetroffen. Beispielsweise sendet oder blockiert ein Netzwerkclient, der abhängig davon, ob eine Verbindung zum Server hergestellt wurde oder nicht, Anforderungen. Oder ein Objekt für die Arbeit mit einer Datenbank, das Sprachfunktionen in eine SQL-Abfrage übersetzen, ausführen, eine Antwort erhalten, in Objekte übersetzen usw. muss.

Bei spezifischeren Aufgaben, wie einem Zahlungsmodul, bei dem ein breiterer Satz von Zuständen, eine komplexe Logik, die Verwendung einer Zustandsmaschine ebenfalls korrekt ist.

Infolgedessen stellen wir fest, dass es in mobilen Anwendungen viele Objekte gibt, deren Zustand und Verhaltenslogik komplizierter beschrieben werden als mit einem Satz. Sie müssen in der Lage sein, zu verwalten.

Betrachten Sie ein reales Beispiel und verstehen Sie, wann eine Finite-State-Maschine wirklich benötigt wird und wo ihre Anwendung nicht gerechtfertigt ist.

Betrachten Sie den ViewController aus der Championship iOS-Anwendung, eine beliebte Sportressource. Dieser Controller zeigt eine Reihe von Kommentaren in tabellarischer Form an. Benutzer geben die Spielbeschreibung ein, zeigen Fotos an, lesen die Nachrichten und hinterlassen ihre Kommentare. Der Bildschirm ist recht einfach: Die darunter liegende Ebene liefert Daten, sie werden verarbeitet und auf dem Bildschirm angezeigt.

Es können entweder reale Daten oder ein Fehler an das Display übertragen werden. Es erscheint also der erste bedingte Operator, der erste Zweig, der das weitere Verhalten der Anwendung bestimmt.

Die nächste Frage ist, was zu tun ist, wenn keine Daten vorhanden sind. Ist dieser Zustand ein Fehler? Höchstwahrscheinlich nicht: Nicht jede Nachricht enthält Benutzerkommentare. Zum Beispiel ist Hockey in Ägypten für niemanden von Interesse, in einem solchen Artikel gibt es normalerweise keine Kommentare. Dies ist normales Verhalten und der normale Zustand des Bildschirms, den Sie anzeigen müssen. Der zweite bedingte Operator wird angezeigt.

Es ist logisch anzunehmen, dass es auch einen Startzustand gibt, in dem der Benutzer Daten erwartet (z. B. wenn der Kommentarbildschirm nur auf dem Bildschirm angezeigt wird). Zeigen Sie in diesem Fall die Ladeanzeige korrekt an. Dies ist die dritte bedingte Aussage.

Wir haben also bereits vier Zustände auf einem einfachen Bildschirm, dessen Anzeigelogik durch das Konstrukt if-else-if-else beschrieben wird.

Aber was ist, wenn es mehr solche Staaten gibt? Die iterative Entwicklung des Bildschirms führt zu einem komplizierten Gewirr von bedingten Konstrukten, einer Reihe von Flags oder einem umständlichen Fall mit mehreren Schaltern. Dieser Code ist beängstigend. Stellen Sie sich vor, der Entwickler, der ihn unterstützt, weiß, wo Sie wohnen, und er hat eine Kettensäge, die er immer bei sich hat. Und Sie möchten Ihrer kleinen, aber wohlverdienten Rente wirklich gerecht werden.

Ich denke, in diesem Fall lohnt es sich zu überlegen, ob es sich lohnt, eine solche Implementierung in der Anwendung zu belassen.

Nachteile

Lassen Sie uns verstehen, was uns an diesem Code nicht gefällt.

Erstens ist es schwer zu lesen .

Da der Code schlecht gelesen wird, ist es für einen neuen Entwickler schwierig, herauszufinden, was genau an einer bestimmten Stelle im Projekt implementiert ist. Dementsprechend wird es viel Zeit in Anspruch nehmen, die Logik des Anwendungsverhaltens zu analysieren - die Kosten für Support und Entwicklung werden steigen .

Dieser Code ist nicht flexibel . Wenn Sie einen neuen Status hinzufügen müssen, der nicht aus der aktuellen Leiter folgt, ist dies möglicherweise überhaupt nicht erfolgreich! Wenn Sie einen Durchgang benötigen - beenden Sie abrupt das Bestehen von Schecks auf dieser Leiter - wie geht das? Fast nichts.

Auch bei diesem Ansatz gibt es keinen Schutz vor fiktiven Staaten . Wenn Übergänge durch einen Switch-Fall beschrieben werden, wird höchstwahrscheinlich das Standardverhalten implementiert. Dieser Zustand ist logisch in Bezug auf das Programmverhalten, aber kaum logisch in Bezug auf die menschliche oder geschäftliche Logik der Anwendung.

Was kann die Lösung für die angegebenen Mängel sein? Dies ist natürlich die Konstruktion der Logik jedes Moduls / Controllers / komplexen Objekts, die nicht auf Intuition basiert, sondern einen guten formalisierten Ansatz verwendet. Zum Beispiel eine endliche Zustandsmaschine.

Gameplaykit

Als Beispiel nehmen wir das, was Apple anbietet. Im Rahmen des GameplayKit-Frameworks gibt es zwei Klassen, die uns bei der Arbeit mit der Zustandsmaschine helfen.

GKState.
GKStateMachine.

Der Name des Frameworks macht deutlich, dass Apple in Spielen verwendet werden wollte. In Nicht-Gaming-Anwendungen ist dies jedoch hilfreich.

Die GKState- Klasse definiert den Status. Um es zu beschreiben, müssen Sie einfache Schritte ausführen. Wir erben von dieser Klasse, legen den Statusnamen fest und definieren drei Methoden.

isValidNextState - Gibt an, ob der aktuelle Status basierend auf dem vorherigen gültig ist.
didEnterFrom - Aktionen beim Übergang in diesen Zustand.
willExitTo - Aktionen beim Verlassen dieses Status.

GKStateMachine ist eine Zustandsmaschinenklasse. Es ist noch einfacher. Es reicht aus, zwei Aktionen auszuführen.

Wir übergeben den Satz von Eingabezuständen über den Initialisierer an das typisierte Array.
Wir machen Übergänge abhängig von den Eingangssignalen mit der Enter-Methode. Dadurch wird auch der Ausgangszustand eingestellt.

Es kann verwirrend sein, dass eine Klasse als Argument an die enter- Methode übergeben wird. Es sollte jedoch beachtet werden, dass ein Objekt einer Klasse nicht in einem Array von Zuständen definiert werden kann - dies verbietet eine strikte Typisierung. Wenn Sie also eine beliebige Klasse als nächste Statusklasse festlegen, geschieht nichts, und die enter-Methode gibt false zurück.

Zustände und Übergänge zwischen ihnen

Nachdem wir uns mit dem Framework von Apple vertraut gemacht haben, kehren wir zum Beispiel zurück. Es ist notwendig, die Zustände und Übergänge zwischen ihnen zu beschreiben. Sie müssen dies auf die verständlichste Weise tun. Es gibt zwei gängige Optionen: eine Tabelle oder ein Übergangsdiagramm. Das Übergangsdiagramm ist meiner Meinung nach eine verständlichere Option. Es ist in UML auf standardisierte Weise. Deshalb wählen wir es.

Im Übergangsdiagramm gibt es Zustände, die durch Namen beschrieben werden, und Pfeile, die diese Zustände verbinden, um Übergänge zu beschreiben. Im Beispiel gibt es einen Anfangszustand - wir erwarten Daten - und es gibt drei Zustände, die vom Anfangszustand aus erreicht werden können: empfangene Daten, keine Daten und Fehler.

In der Implementierung erhalten wir vier kleine Klassen.

Lassen Sie uns den Status "Daten ausstehend" analysieren. Am Eingang lohnt es sich, die Download-Anzeige anzuzeigen. Und wenn Sie diesen Zustand verlassen , verstecken Sie ihn. Dazu benötigen Sie eine schwache Verbindung zum ViewController, der von der erstellten Zustandsmaschine gesteuert wird.

Maschinenparameter

Der zweite Schritt, der ausgeführt werden muss, besteht darin, die Parameter der Zustandsmaschine einzustellen. Erstellen Sie dazu Zustände und übertragen Sie diese auf das Automatenobjekt.

Stellen Sie außerdem sicher, dass Sie den Ausgangszustand festlegen

Grundsätzlich ist die Maschine alles bereit. Jetzt ist es notwendig, Reaktionen auf externe Ereignisse zu verarbeiten und den Zustand des Automaten zu ändern.

Erinnern Sie sich an die Erklärung des Problems. Wir haben eine Leiter von if-else bekommen, auf deren Grundlage entschieden wurde, welche Aktion durchgeführt werden soll. Als Steuerung für einen einfachen Automaten kann eine solche Implementierungsoption sein (in der Tat ein einfacher Schalter - dies ist eine primitive Implementierung einer endlichen Zustandsmaschine), aber wir werden die zuvor erwähnten Nachteile praktisch nicht beseitigen.

Es gibt einen anderen Ansatz, mit dem Sie von diesen Leitern wegkommen können. Es wird von den Klassikern der Programmierung vorgeschlagen - der sogenannten "Viererbande".

Es gibt ein spezielles Entwurfsmuster, das als "Status" bezeichnet wird.

Dies ist ein Verhaltensmuster ähnlich einer Strategie, die eine Zustandsmaschinenabstraktion beschreibt. Es ermöglicht dem Objekt, sein Verhalten je nach Status zu ändern. Der Hauptzweck der Anwendung besteht darin , das Verhalten und die Daten, die einem bestimmten Status zugeordnet sind, in einer separaten Klasse zusammenzufassen. Somit sendet die Zustandsmaschine, die anfänglich die Entscheidung getroffen hat, welchen Zustand sie verursachen soll, nun ein Signal, übersetzt es in einen Zustand und der Zustand trifft eine Entscheidung. Entladen Sie die Leiter also teilweise, und die Verwendung des Codes wird angenehmer.

Das Standard-Framework weiß nicht wie. Er schlägt vor, dass GKStateMachine die Entscheidung treffen wird. Daher erweitern wir die endliche Zustandsmaschine mit einer neuen Methode, bei der wir als Konfiguration die Beschreibung aller bedingten Variablen übergeben, die den nächsten Zustand eindeutig bestimmen. Innerhalb dieser Methode können Sie die Auswahl des nächsten Status an den aktuellen delegieren.

Es wird empfohlen, den Status mit einem Objekt zu beschreiben und ihn immer weiterzugeben, anstatt viele, viele Eingabeparameter zu schreiben. Als nächstes delegieren wir die Auswahl des nächsten Zustands an den aktuellen. Das ist das ganze Upgrade.

Vorteile von GameplayKit.

Standardbibliothek. Sie müssen nichts herunterladen, keine Cocoapods oder Karthago verwenden.
Die Bibliothek ist recht einfach zu erlernen.
Es gibt zwei Implementierungen gleichzeitig: auf Objective-C und auf Swift.

Nachteile:

Realisierungen von Zuständen und Übergängen sind eng miteinander verbunden.
Das Prinzip der alleinigen Verantwortung wird verletzt: Der Staat weiß, wohin und wie es geht.
Doppelte Zustände werden in keiner Weise kontrolliert.
Ein Array wird an die Zustandsmaschine übergeben, nicht viele Zustände. Wenn Sie mehrere identische Zustände übertragen, wird der letzte aus der Liste verwendet.

Was sind die Implementierungen der endlichen Zustandsmaschine noch? Schauen Sie sich GitHub an.

Objective-C-Implementierungen

TransitionKit

Dies ist seit langem die beliebteste Objective-C-Bibliothek, ohne die in GamePlayKit festgestellten Mängel. Es ermöglicht uns, eine Zustandsmaschine und alle damit verbundenen Aktionen auf Blöcken zu implementieren.

Der Zustand ist von Übergängen getrennt .

Innerhalb von TransitionKit gibt es 2 Klassen.

TKState - zum Festlegen von Status- und Eingabe- und Ausgabeaktionen.
TKEvent ist eine Klasse zur Beschreibung des Übergangs.
TKEvent bindet einige Zustände an andere. Das Ereignis selbst wird einfach durch eine Zeichenfolge definiert.

Darüber hinaus gibt es zusätzliche Vorteile.

Sie können nützliche Daten während des Übergangs übertragen . Dies funktioniert genauso wie bei Verwendung von NSNotificationCenter. Alle nützlichen Nutzdaten werden in Form eines userInfo-Wörterbuchs bereitgestellt, und der Benutzer analysiert die Informationen.

Der fehlerhafte Übergang hat eine Beschreibung . Wenn wir versuchen, einen nicht vorhandenen - unmöglichen Übergang durchzuführen - erhalten wir nicht nur den NO-Wert, wenn wir von der Übergangsmethode zurückkehren, sondern auch eine detaillierte Beschreibung des Fehlers, die beim Debuggen einer Zustandsmaschine hilfreich ist.

TransitionKit wird im beliebten RestKit Network Harvester verwendet. Dies ist ein ziemlich gutes Beispiel dafür, wie eine Zustandsmaschine im Anwendungskernel bei der Implementierung von Netzwerkoperationen verwendet werden kann.

RestKit verfügt über eine spezielle Klasse - RKOperationStateMachine - zum Verwalten gleichzeitiger Vorgänge. An der Eingabe akzeptiert es die zu verarbeitende Operation und die Warteschlange für ihre Ausführung.

Intern ist die Zustandsmaschine sehr einfach: drei Zustände (bereit, ausgeführt, abgeschlossen) und zwei Übergänge: Start und Ende der Ausführung. Nach dem Start der Verarbeitung (und bei allen Übergängen) beginnt die Zustandsmaschine, einen vordefinierten Benutzercodeblock in der beim Erstellen der Warteschlange angegebenen Warteschlange zu steuern.

Eine mit ihrem Automaten verknüpfte Operation überträgt externe Ereignisse an den Automaten und führt Übergänge zwischen Zuständen und allen zugehörigen Aktionen durch. State Machine kümmert sich darum

asynchrone Codeausführung,
Atomcode-Ausführung während Übergängen,
Übergangskontrolle
Betriebsstornierung
Die Richtigkeit der Änderung der Betriebszustandsvariablen: isReady, isExecuting, isFinished.

Verschiebung

Neben TransitionKit ist Shift zu erwähnen - eine winzige Bibliothek, die als Kategorie über NSObject implementiert ist. Mit diesem Ansatz können Sie jedes Objekt in eine Zustandsmaschine verwandeln und seinen Zustand in Form von Zeichenfolgenkonstanten und Aktionen in Blöcken während Übergängen beschreiben. Dies ist natürlich eher ein Schulungsprojekt, aber sehr interessant und ermöglicht es Ihnen, zu minimalen Kosten zu testen, was eine Zustandsmaschine ist.

Schnelle Implementierungen

Es gibt viele Implementierungen von Finite-State-Maschinen in Swift. Ich werde eines herausgreifen ( Bemerkung : Leider hat sich das Projekt in den letzten zwei Jahren nach dem Bericht nicht weiterentwickelt, aber die darin enthaltenen Ideen sind es wert, im Artikel erwähnt zu werden).

SwiftyStateMachine

In SwiftyStateMachine wird die Zustandsmaschine durch eine nicht stabile Struktur dargestellt. Mit den didSet-Methoden der Eigenschaft können Sie Statusänderungen leicht abfangen.

In dieser Bibliothek wird die Zustandsmaschine durch die Entsprechungstabelle von Zuständen und Übergängen zwischen ihnen definiert. Dieses Schema wird getrennt von dem Objekt beschrieben, das die Maschine steuern wird. Dies wird durch einen verschachtelten Switch-Fall implementiert.

Hauptmerkmale, Vorteile dieser Bibliothek sind.

Die Notwendigkeit, das Zustandsübergangsschema vollständig zu beschreiben.
Auf diese Weise können Sie in der Kompilierungsphase einen Fehler erhalten, wenn der Übergang für einen bestimmten Status nicht verarbeitet wird.
Strikte Kontrolle der Eingangssignale.
Sie können kein Signal an eine Zustandsmaschine übergeben, die nicht definiert ist oder die für eine andere Zustandsmaschine definiert ist.
Durch die Trennung der Schaltung und des von ihr gesteuerten Objekts können Sie Zeit bei der Initialisierung der Maschine sparen.
Visualisierung mit der DOT-Grafikbeschreibungssprache.
Es gibt eine grafische Auszeichnungssprache für die Arbeit mit Zustandsdiagrammen - DOT. Diese Bibliothek gibt damit an, wie die Zustandsmaschine gerendert wird.