Zustand (Entwurfsmuster)

Der Zustand (engl. State) ist ein Entwurfsmuster aus dem Bereich der Softwareentwicklung und gehört zu der Kategorie der Verhaltensmuster (Behavioral Patterns). Das Zustandsmuster wird verwendet, um Änderungen des Verhaltens eines Objekts abhängig von seinem Zustand zu ermöglichen.

Das Zustandsmuster ist eines der so genannten GoF-Muster. Auch bekannt als Objekte für Zustände (Objects for States).

Verwendung

Das Verhalten eines Objekts ist abhängig von seinem Zustand.
Die übliche Implementierung soll vermieden werden, die Zustände eines Objekts und das davon abhängige Verhalten in einer großen Switch-Anweisung (basierend auf enumerierten Konstanten) zu kodieren. Jeder Fall der Switch-Anweisung soll in einer eigenen Klasse implementiert werden, so dass der Zustand des Objektes selbst wieder ein Objekt ist, das unabhängig von anderen Objekten ist.

Problem

Zustandsautomat

Für ein Objekt sind verschiedene Zustände, die möglichen Übergänge zwischen diesen Zuständen und das davon abhängige Verhalten zu definieren. Dies ist hier in Form eines endlichen Automaten dargestellt. Dabei zeigt der schwarze Kreis auf den Startzustand und der schwarze Kreis mit der weißen Umrandung auf den Endzustand. Die gerichteten Kanten (Pfeile) zwischen den Zuständen Closed, Open und Deleted definieren den Zustandswechsel.

Hierarchische Zustandsautomat

Ein einzelner Zustand eines Objektes kann wiederum in eine Anzahl verschiedener Zustände aufgeteilt werden. Den Zustand Open kann man beispielsweise unterteilen in Read und Wrote. Sie bilden einen zusammengesetzten Zustand Open. Closed sowie Deleted betrachtet man unabhängig vom zusammengesetzten Zustand Open. Diese Zustände kann man in einer Hierarchie anordnen. Open, Closed und Deleted sind in der ersten Ebene. In der zweiten Ebene befinden sich Read und Wrote, die dem Zustand Open zugeordnet sind.

Lösung

Einfache Zustände

Das zustandsabhängige Verhalten des Objekts wird in separate Klassen ausgelagert, wobei für jeden möglichen Zustand eine eigene Klasse eingeführt wird, die das Verhalten des Objekts in diesem Zustand definiert. Damit das ursprüngliche Objekt die separaten Zustandsklassen einheitlich behandeln kann, wird eine gemeinsame Abstrahierung dieser Klassen definiert. Bei einem Zustandsübergang tauscht das ursprüngliche Objekt das von ihm verwendete Zustandsobjekt aus.

Implementierung

Für das Ausprogrammieren des Zustandsmusters sollte vorher überlegt werden, ob

der Kontext die Zustände als Attribute hält.
bei jedem Zustandswechsel der vorherige Zustand gelöscht und ein neuer Zustand instantiiert wird, was zwar rechentechnisch aufwendiger aber sauberer für den Programmablauf ist. D.h., dass alle Membervariablen eines jeden Zustands gelöscht werden und ein evtl. späteres Debuggen von Anfang an ausgeschlossen wird. Man kann dann auch diesen Zustand mehrmals in ähnlichen Kontexten verwenden. (z.B. Zwei Dateien können in einem Dateisystem zur gleichen Zeit geöffnet sein. Dabei befinden sich jeweils die Dateien im Zustand: Open. Vom Open-Zustand existieren daher zwei Instanzen, jeweils eine Instanz für eine Datei.)
jeder Zustand nur einmal erzeugt wird - dann wenn er zum ersten Mal gebraucht wird - und daher alle möglichen Zustände parallel im Speicher existieren (hier wird das Singleton-Erzeugermuster verwendet).

Akteure

Kontext
- Definiert die klientseitige Schnittstelle.
- Verwaltet die separaten Zustandsklassen und tauscht diese bei einem Zustandsübergang aus.
Zustand
- Definiert eine einheitliche Schnittstelle aller Zustandsobjekte.
- Implementiert gegebenenfalls ein Standardverhalten. Beispielsweise kann im Zustand die Ausführung jeglichen Verhaltens gesperrt werden. Das Verhalten kann in diesem Falle nur dann ausgeführt werden, wenn es vom konkreten Zustand durch Überschreiben der entsprechenden Methode freigeschaltet wurde.
Konkreter Zustand
- Implementiert das Verhalten, das mit dem Zustand des Kontextobjekts verbunden ist.

Vorteile

Komplexe und schwer leserliche Bedingungsanweisungen können vermieden werden.
Neue Zustände und neues Verhalten können auf einfache Weise hinzugefügt werden. Die Wartbarkeit wird erhöht.
Zustandobjekte können wiederverwendet werden.

Nachteile

Bei sehr einfachem zustandsbehaftetem Verhalten rechtfertigt unter Umständen der Implementierungsaufwand nicht den Nutzen.

Beispiel

Prinzipiell kann jedes zustandsabhängige Verhalten durch dieses Entwurfsmuster abgebildet werden. Einige Beispiele für zustandsbehaftete Problemstellungen sind

Verwaltung von Sessions
Verwaltung von Ein- und Ausgabeströmen
Zustandbehaftete Bedienelemente einer grafischen Benutzeroberfläche
Parkautomaten

Idiome

C#

using System;

namespace Wikipedia.Patterns
{
    class File
    {
        public File()
        {
            Console.WriteLine("Creating a closed file.");
            myState = ClosedState.Instance;
        }

        public void Open() { myState.Open(this); }
        public void Close() { myState.Close(this); }
        public void Delete() { myState.Delete(this); }

        internal void ChangeState(State state)
        {
            myState = state;
        }

        private State myState;
    };


    abstract class State
    {
        internal virtual void Open(File file)
        {
            Console.WriteLine("State.Open does nothing by default.");
        }

        internal virtual void Close(File file)
        {
            Console.WriteLine("State.Close does nothing by default.");
        }

        internal virtual void Delete(File file)
        {
            Console.WriteLine("State.Delete does nothing by default.");
        }
    };

    class OpenState : State
    {
        public static readonly OpenState Instance = new OpenState();

        internal override void Close(File file)
        {
            Console.Write("OpenState.Close will close the file now.");
            file.ChangeState(ClosedState.Instance);
            Console.WriteLine(" The file is now closed.");
        }
    };

    class ClosedState : State
    {
        public static readonly ClosedState Instance = new ClosedState();

        internal override void Open(File file)
        {
            Console.Write("ClosedState.Open will open the file now.");
            file.ChangeState(OpenState.Instance);
            Console.WriteLine(" The file is now open.");
        }

        internal override void Delete(File file)
        {
            Console.Write("OpenState.Delete will delete the file now.");
            file.ChangeState(DeletedState.Instance);
            Console.WriteLine(" The file is now deleted.");
        }
    };

    class DeletedState : State
    {
        public static readonly DeletedState Instance = new DeletedState();
    };

    class MainClass
    {
        public static void Main()
        {
            File file = new File();

            file.Open();
            file.Open();
            file.Close();
            file.Close();
            file.Delete();
            file.Delete();

            Console.ReadLine();
        }
    };
}

Die Ausgabe dieses Programmes ist:

Creating a closed file.
ClosedState.Open will open the file now. The file is now open.
State.Open does nothing by default.
OpenState.Close will close the file now. The file is now closed.
State.Close does nothing by default.
OpenState.Delete will delete the file now. The file is now deleted.
State.Delete does nothing by default.

Entwurfsmuster der Viererbande

Erzeugungsmuster: Fabrikmethode | Abstrakte Fabrik | Erbauer | Prototyp | Einzelstück