Objektorientierte Entwurfsmuster - Architektur und Entwurfsmuster der Softwaretechnik - page 204

von Rollen wäre aber eine solche Klasse auf Grund der Kombinationsmöglichkeiten
bald zu komplex und zu unübersichtlich. Außerdem ist es für eine Anwendung nicht
ohne weiteres ersichtlich, welche Rollen ein Objekt gerade einnimmt und welche Me-
thoden bei dem Objekt auf Grund seiner Rollen sinnvoll aufgerufen werden können.
Eine weitere und innerhalb der Objektorientierung am häufigsten verwendete Technik
zur Modellierung von Rollen ist die statische Vererbung ( Spezialisierung durch Ab-
leitung ). So würden in diesem Fall die Rollen Verkauf , Entwicklung und Con-
trolling jeweils statisch von der Kernklasse Mitarbeiter erben. Solange die In-
stanzen jeweils nur eine einzige Rolle statisch übernehmen, wäre die Vererbung eine
ausreichende Lösung. Sollte jedoch - beispielsweise in einer kleinen Firma - ein Mit-
arbeiter gleichzeitig mit Verkauf und Controlling beschäftigt sein, würde diese einfache
Lösung nur bei einer Sprache, die Mehrfachvererbung unterstützt funktionieren - also
nicht in Java. Der Lösungsansatz ist aber auch mit Mehrfachvererbung problematisch,
da für jede mögliche Rollenkombination eine Klasse definiert werden muss. Ferner
wäre es für einen Mitarbeiter nicht möglich, seine Rolle dynamisch zu wechseln.
Das dynamische Wechseln einer Rolle ist sehr schwierig zu realisieren. In den meisten
objektorientierten Programmiersprachen 61 kann ein Objekt nicht mehr seine Klasse
wechseln. Es sind implizit nur Typumwandlungen in die Oberklassen möglich, von de-
nen die Klasse eines Objekts erbt (sogenannte Up-Casts ). Bei einem Up-Cast gehen
keine Informationen verloren und das Grundgerüst eines Objekts bleibt identisch - ein
Up-Cast stellt nur eine eingeschränkte Sicht auf ein Objekt dar. Somit müsste für einen
Rollenwechsel ein neues Objekt erzeugt werden, das alle relevanten Informationen
von dem ursprünglichen Objekt kopiert. Alle im System vorhandenen Referenzen müs-
sten so aktualisiert werden, dass sie auf das neue Objekt verweisen. Dies ist für eine
praktikable Lösung zu umständlich.
Einen Lösungsansatz, der einen Rollenwechsel erlaubt, bietet das Verhaltensmuster
Zustand (siehe Kapitel 4.14). Jedes Objekt der Klasse Mitarbeiter erhält - analog
zu Bild 4-46 - jeweils einen Zustand, der beschreibt, welche Rolle von diesem Mitar-
beiter gerade ausgeführt wird. Zur Laufzeit kann dann zwischen den einzelnen Zu-
ständen - oder besser gesagt: zwischen den einzelnen Rollen - gewechselt werden.
Allerdings ist es bei dieser Lösung für ein Objekt nicht so ohne weiteres möglich, ver-
schiedene Rollen gleichzeitig anzunehmen. Ebenfalls nachteilig ist, dass alle Rollen
die gleiche Schnittstelle haben müssten.
Lösungsansatz des Rollenmusters
Das Entwurfsmuster Rolle basiert auf einem ähnlichen Grundgedanken wie das Ent-
wurfsmuster Zustand: Analog zum Zustandsmuster, wo jeder Zustand in einem eige-
nen Objekt gekapselt wird, wird im Rollenmuster jede Rolle durch ein eigenes Objekt
repräsentiert.
61 Eine Ausnahme bilden typenlose Sprachen wie JavaScript.