-LABORPRAKTIKUM- SOMMERSEMESTER 2005 Umsetzung von Pattern Muster: State Gruppe: Christian Wolff...

-LABORPRAKTIKUM-SOMMERSEMESTER 2005

„Umsetzung von Pattern“

Muster: State

Gruppe: Christian WolffMarita Schwaß

Quelle:Gamma, E., Helm, R., Jonson, R., Vlissides, J.,„Entwurfsmuster“, Addison Wesley, Bonn, 1996

State – Muster (Zustand)

Laborpraktikum„Umsetzung von

Pattern“

1/15

Christian WolffMarita Schwaß

Fernstudium InformatikMatrikel 2000

Schwerpunkte :

1. Zweck

2. Motivation

3. Struktur

4. Interaktion

5. Konsequenzen

6. Implementierung

7. Verwandte Muster

1. Zweck


Pattern“

1. Zweck2. Motivation3. Struktur4. Interaktion5. Konsequenzen6. Implementierung7. Verwandte Muster

2/15Christian WolffMarita Schwaß


Es soll einem Objekt möglich sein,

sein Verhalten zu ändern,

wenn sich sein interner Zustand ändert.

Das Objekt scheint dann seine Klasse zu ändern.

Variante:Der interne Zustand eines Objektes ändert sich.

2. MotivationLaborpraktikum„Umsetzung von

Pattern“

1. Zweck 2. Motivation3. Struktur4. Interaktion5. Konsequenzen6. Implementierung7. Verwandte Muster



Beispiel Lichtautomat:

1. Zustand = Klasse

2. Motivation


Pattern“




2. Verallgemeinerung

2. Motivation


Pattern“




3. Aggregation zur Automaten-Klasse

2. Motivation


Pattern“




4. Java-Code

3. Struktur


Pattern“




Kontext: - definiert die den Klienten interessierende Schnittstelle- verwaltet ein Exemplar einer KonkreterZustand-

Unterklasse, welche den aktuellen Zustand definiert

Zustand: - definiert Schnittstelle zur Kapselung des mit einem be- stimmten Zustand des Kontextobjekts verbundenen

Verhalten

KonkreterZustand: - jede Unterklasse beinhaltet ein Verhalten, das mit einem Zustand des Kontextobjekts verbunden ist

4. Interaktion


Pattern“




1. Kontextobjekt delegiert zustandsspezifische Anfragen an das aktuelle KonkreterZustand-Objekt.

2. Ein Kontext kann sich selbst als Argument an das die Anfrage bearbeitende Zustandsobjekt mitgeben. Dadurch ist es dem

Zustandsobjekt möglich, ggf. auf das Kontextobjekt zuzugreifen.

3. Das Kontextobjekt bietet die für die Kunden interessante Schnittstelle. Der Kunde kann ein Kontextobjekt mit Zustandsobjekten konfigurieren. Ist ein Kontextobjekt einmal konfiguriert, braucht sich der Kunde nicht mehr direkt mit den Zustandsobjekten befassen.

4. Welche Zustände aufeinander folgen und unter welchen Bedingungen sie dies tun, kann sowohl von der Kontext- als auch den KonkreterZustand-Unterklassen bestimmt werden.

5. Konsequenzen


Pattern“




1. Das Zustandsmuster lokalisiert zustandspezifisches Verhalten und teilt das Verhalten in unterschiedliche

Zustände auf.

- Der gesamte zustandsspezifische Code ist in einer Zustands- unterklasse neue Zustände und Zustandsübergänge können

einfach durch Definition einer neuen Unterklasse hinzugefügt werden.

- Logik der Zustandsübergänge ist auf die Zustandsunterklassen verteilt leichter zu überschauen und zu warten

2. Zustandsobjekte können gemeinsam genutzt werden.

- Wenn Zustandsobjekte über keine Exemplarvariablen verfügen, dann können Kontextobjekte ein Zustandsobjekt

gemeinsam nutzen.

6. Implementierung


Pattern“




1. Definition der Zustandsübergänge

- Im Zustandsmuster ist nicht bestimmt, welcher Teilnehmer die Kriterien der Zuständeübergänge definiert.

- Ändern sich die Kriterien nicht, könnten sie direkt im Kontextobjekt implementiert werden.

- Flexibler ist es jedoch, wenn die Zustandsklassen ihren Nachfolgezustand und wann der Übergang erfolgen soll, selbst angeben. Kontextobjekt erhält weitere Schnittstelle, die es den Zustandsobjekten ermöglicht, den aktuellen Zustand des Kontextobjekts explizit zu setzen.

6. Implementierung


Pattern“




2. Erzeugen und Löschen von Zustandobjekten

Frage: Sollen Zustandsobjekte nur bei Bedarf erzeugt werden und danach gelöscht werden (1) oder

im voraus erzeugt und danach niemals gelöscht werden(2).

(1) Sollte genutzt werden, wenn die möglichen Eingabezustände zur Laufzeit bekannt sind und sich die Kontextobjekte selten ändern.

(2) Sollte genutzt werden, wenn die Zustandsänderungen schnell und häufig sind.

6. Implementierung


Pattern“




3.Alternativen zur Realisierung von Zustandsdiagrammen

3.1. Tabellenbasierte Alternative

Idee: Jeder Zustand hat eine Tabelle, in der jede mögliche Eingabe auf einen Nachfolgezustand abgebildet wird.

Vorteil: regelmäßige Struktur der Tabelle

Übergangskriterien können durch die Modifikation von Daten festgelegt werden, statt durch Programmcode.

Nachteil: Übergänge sind weniger explizit zu sehen und daher schwerer zu warten

Aktionen während eines Zustandsüberganges sind schwierig einzubinden.

6. Implementierung


Pattern“




3.2. Logische Ausdrücke

Vorteile:äußerst kompakt, ideal für Hardwarerealisierung

Nachteile:Minimierung der Zustandsübergangstabelle nötig, schlechterweiterbar

3.3. Case-Anweisungen

Vorteile:geeignet für procedurale Sprachen, relativ kompakt

Nachteile:verschachtelte Case/If-then-Konstrukte, unübersichtlich, schlechterweiterbar

6. Implementierung


Pattern“




3.4. State - Muster

Vorteile:

geeignet für objektorientierte Sprachen,gut erweiterbar, übersichtlich,hohe Verfolgbarkeit vom Zustandsdiagramm zum Code

Nachteile:

viele Klassen (Code) mit hoher Ähnlichkeit

7.Verwandte Muster


Pattern“




Fliegengewichtmuster:

erläutert, wann und wie Zustandsobjekte gemeinsam genutzt werden können.

Singletons:

Zustandsobjekte sind oft Singletons

-LABORPRAKTIKUM- SOMMERSEMESTER 2005 Umsetzung von Pattern Muster: State Gruppe: Christian Wolff...

Documents

Transcript of -LABORPRAKTIKUM- SOMMERSEMESTER 2005 Umsetzung von Pattern Muster: State Gruppe: Christian Wolff...