Das State-Pattern - Des Kaisers neue Kleider

Marc++us

Das State-Pattern - des Kaisers neue Kleider

Objektorientierte Programmierung Für Dummies | ISBN: 9783527700578Der folgende Text war ursprünglich für mein Buch „Objektorientierte Programmierung für Dummies“ geschrieben worden, und hätte im Buch ab Seite 424 erscheinen sollen. Aus Platzgründen wurde er aber nicht mehr berücksichtigt.

Inhalt

In diesem Artikel erfahren Sie, wie man mit Hilfe des State-Pattern das Innenleben von Objekten ändert, ohne dass man es von außen sieht und als Benutzer oder Besitzer eines Objekts bemerkt. Dadurch wird die Kopplung eines übergeordneten Objekts zu dem benutzten Objekt reduziert.

1 Motivation – des Kaisers neue Kleider
2 Das State-Pattern
3 Das Pimpl-Idiom
4 Zusammenfassung

1 Motivation – des Kaisers neue Kleider

Menschen ändern sich, Objekte auch. Nehmen Sie eine Spielfigur, die in zwei Modi unterwegs sein kann: laufend und schwimmend. Oder kämpfend und bauend. Wer es bodenständiger mag, nimmt einen Server, der an einem Netzwerk hängt. Mal wartet der Server auf Verbindungen, mal besteht eine aktive Verbindung, mal geht der Server in einen Fehlerzustand.
Alle diese Dinge haben eines gemeinsam, in Abhängigkeit seines Zustands ändert ein Objekt sein Verhalten. Nehmen Sie an, dass sich zwei Zustände durch zwei Klassen beschreiben lassen, so könnte man das ja ungefähr so aussehen lassen:

class State1 : public BasisState;
class State2 : public BasisState;

BasisState* pState = new State1();
pState->doSomething();
delete pState;

pState = new State2();
pState->doSomething();
delete pState;

Über eine virtuelle Methode kann das Objekt pState sich dann je nach Zustand richtig verhalten. Eine gute Lösung? Leider nein. Bedenken Sie, dass andere Objekte bereits Zeiger und Referenzen auf dieses Objekt besitzen können. Und nun wollen Sie alle bestehenden Zeiger und Referenzen durch neue ersetzen?
Das geht nicht. Das Objekt selbst darf sich für einen Außenstehenden nicht verändern.

2 Das State-Pattern

Ein Entwurfsmuster, das dieses Problem löst, nennt sich State-Pattern. Um ein Objekt seinen inneren Zustand ändern zu lassen, benötigt man insgesamt vier Klassen (für zwei Zustände). Wollte man drei Zustände modellieren, bräuchte man fünf Klassen (für n Zustände immer 2 + n Klassen).

Die Abbildung zeigt den Zusammenhang zwischen den vier Klassen bei der Realisierung des State-Pattern.

Von außen wird nur die Klasse Dummy sichtbar. Intern gibt es für jeden Zustand eine eigene Klasse, diese sind von einer gemeinsamen Basisklasse abgeleitet. Jede Methode von Dummy hat eine entsprechende virtuelle Methode in InnerDummy .
Betrachten Sie ein Programmbeispiel zunächst aus Sicht des Aufrufers.

#include <iostream>
#include "dummy.h"
using namespace std;
int main()
{
   Dummy dummy(5);
   for (int i = 0; i < 1000; i++)
   {
      dummy.doSomething();
      dummy.showValue();
   }
   return 0;
}

Wie Sie sehen können, erfährt man als Nutzer der Klasse Dummy nichts von deren Eigen- und Innenleben. Das ist schon mal ein guter Beginn. Nun geht es weiter zu den inneren Klassen.

#ifndef DUMMY_H
#define DUMMY_H
class Dummy;
class InnerDummy
{
public:
   virtual void showValue(Dummy* pDummy) = 0;
};
class InnerDummyA : public InnerDummy
{
public:
   virtual void showValue(Dummy* pDummy);
};
class InnerDummyB : public InnerDummy
{
public:
   virtual void showValue(Dummy* pDummy);
};
class Dummy
{
public:
   Dummy(int value);
   ~Dummy();
   void showValue()
   {
      pDummy->showValue(this);
   }
   void doSomething();
   int getValue() const
   {
      return value;
   }
private:
   InnerDummy* pDummy;
   int value;
};
#endif

Beachten Sie, dass es für die Methode Dummy::showValue auch noch virtuelle Methoden in InnerDummy (und natürlich auch den abgeleiteten Klassen) gibt. Zudem besitzt Dummy einen Zeiger auf InnerDummy – wozu sehen Sie, sobald Sie sich die mplementation betrachten.

#include <iostream>
#include "dummy.h"
using namespace std;
void InnerDummyA::showValue(Dummy* pDummy)
{
   cout << "Jetzt bin ich A! "
        << pDummy->getValue() <<endl;
}
void InnerDummyB::showValue(Dummy* pDummy)
{
   cout << "Jetzt bin ich B! "
        << pDummy->getValue() << endl;
}
Dummy::Dummy(int value)
   : value(value)
{
   pDummy = new InnerDummyA();
}
Dummy::~Dummy()
{
   delete pDummy;
}
void Dummy::doSomething()
{
   InnerDummy* new_dummy; 
   if (rand() % 2) 
   { 
      new_dummy = new InnerDummyA(); 
   } 
   else 
   { 
      new_dummy = new InnerDummyB(); 
   } 
   delete pDummy; 
   pDummy = new_dummy; 
}

Jede der show -Methoden wird in InnerDummyA und InnerDummyB anders implementiert, das ist auch logisch, schließlich ändert sich mit dem Zustand das Verhalten. Im Konstruktor von Dummy wird zunächst ein InnerDummyA -Objekt erzeugt, das Objekt befindet sich zu Beginn im Zustand »A«. Ruft man von außen Dummy::showValue auf, so wird in Wirklichkeit die virtuelle Methode des zurzeit eingehängten InnerDummy -Objekts aufgerufen. Je nach Zustand des Objekts Dummy also eine andere Methode.
In der Funktion doSomething wird ein Zustandswechsel simuliert, hier einfach durch die Auswertung einer Zufallszahl. Je nach Ergebnis wechselt das Dummy-Objekt mal in den Zustand »A«, mal in den Zustand »B«. Sie sehen an der Bildschirmausgabe, dass der Aufrufer immer showValue aufruft, die Ausgabe aber dennoch unterschiedlich sein kann.

3 Das Pimpl-Idiom

Rein technisch sieht das State-Pattern einem anderen Trick sehr ähnlich, dem so genannten Pimpl-Idiom. Dort besitzt eine äußere Klasse nur einen Zeiger auf eine innere Klasse und sonst nichts, ganz ähnlich zum State-Pattern:

class Inner;
class Outer
{
public:
   Outer()
   {
      pImpl = new Inner();
   }
   ~Outer()
   {
      delete pImpl;
   }
   void doSomething()
   {
      pImpl->doSomething();
   }
private:
   Inner* pImpl;
};

Auch hier ist es so, dass die Klasse Inner genau die gleichen Methoden besitzt wie die äußere Klasse Outer , aber nicht, um Zustände zu modellieren. Der Gag an Pimpl ist, dass man die komplette Klasse Inner in einer anderen Datei implementieren kann. Hat Sie nicht auch schon oft gestört, dass bei der Ergänzung einer privaten Variablen in einer Klasse plötzlich alles neu kompiliert werden muss? Bei Pimpl wird dies vermieden, da sämtliche privaten Variablen und Methoden nur in Inner realisiert werden. Die Klasse Outer ändert sich dadurch nicht und man kann Inner verändern, ohne das komplette Projekt neu kompilieren zu müssen, es reicht aus, Inner neu zu übersetzen. Pimpl nennt man deshalb auch Compiler-Firewall.

Der Begriff Pimpl kommt von pointer to implementation und erinnert daran, dass ein Zeiger auf das tatsächliche Implementations-Objekt benutzt wird, um die Klasse zu realisieren. Das Pimpl-Idiom wird oft in größeren Open-Source-Projekten verwendet, in denen viele Leute viele verschiedene Dateien bearbeiten.

4 Zusammenfassung

Das State-Pattern ermöglicht es einem Objekt je nach innerem Zustand ein anderes Verhalten zu zeigen.

Implementiert wird das State-Pattern dadurch, dass man für jeden Zustand eine eigene Klasse realisiert. Diese besitzen eine gemeinsame Basisklasse. Für jede Funktion, deren Verhalten sich ändern soll, wird in der Basisklasse eine virtuelle Methode angelegt, die in den abgeleiteten Klassen überschrieben wird. Ruft man von außen eine Methode des Objekts auf, wird in Wirklichkeit eine Methode des gerade aktiven inneren Zustand-Objekts aufgerufen.

Interessant ist das State-Pattern auch, falls jeder Zustand des Objekts noch eigene Variablen benötigt. Packt man alles in eine einzige Klasse, so landen letztlich viele Variablen in einer einzigen Klasse, die aber je nach Zustand immer nur einen Teil benötigt. Bei der State-Lösung ist jede Zustand-Klasse so schlank wie möglich.

Hallo Marc++us,

da ich das Pattern gerade benötige, kam dein Artikel genau zur rechten Zeit
Habe allerdings noch ne Ergänzung:
So wie du das State-Pattern beschrieben hast, könnte man es leicht mit dem Strategy-Pattern verwechseln.
Der Unterschied ist aber, dass die State-Objekte normalerweise selbst darauf Einfluss haben, welches das "Folge-Objekt" des States ist.
Die Dummy-Klasse müsste beispielsweise noch eine Methode wie setNextState(InnerDummy* next) haben. Darüber hinaus sind State-Objekt häufig als Singletons implementiert. Die Literatur beschreibt die Implementierung der Transitions aber leider auch nicht so genau.

Hier ist das nochmal recht gut beschrieben:
http://sourcemaking.com/design_patterns/state

chashprogramist

Die Template-Klasse ist ein ausgezeichnetes Beispiel dafür, Staatsministerin für Wissenschaft! Vielen Dank für den Artikel und, wenn Sie kann für mehrere dieser!

Standard Zustand hatten wir in der Klasse von der Analyse und Gestaltung von IT-Systemen, aber dank Ihren Artikel habe ich verstanden, es besser!

AlGaN

Hallo Marc++us,

sorry für eine mgl.weise dumme Frage: Ich hab mir dein Buch "Objektorientierte Programmierung für Dummies" gekauft, da das Buch nicht mehr gedruckt wird, gibt es auf der Seite des Verlags keinen Link mehr für den Beispielcode. Deshalb meine Frage: Wo kann man sich die Beispiele vom Buch noch downloaden?

Danke,
AlGaN

pumuckl

AlGaN schrieb:

Hallo Marc++us,

sorry für eine mgl.weise dumme Frage: Ich hab mir dein Buch "Objektorientierte Programmierung für Dummies" gekauft, da das Buch nicht mehr gedruckt wird, gibt es auf der Seite des Verlags keinen Link mehr für den Beispielcode. Deshalb meine Frage: Wo kann man sich die Beispiele vom Buch noch downloaden?

Danke,
AlGaN

Ich bezweifle das Marcus hier allzuoft reinschaut. Bessere chancen hast du vermutlich wenn du ihn direkt anschreibst über die Mailing-Funktion hier im Forum.

Tyrdal

war Unsinn

hm guter artikel eigtl...was ich aber schade und etwas komisch finde, dass du den klassen nicht-sagende namen wie dummy gegeben hast...

Erhard Henkes

Ich habe das State Pattern Design beim Hobby-Roboter Nibo auf einem ATmega128 eingesetzt: http://www.henkessoft.de/Roboter/Nibo.htm#mozTocId872713