Java Reference
In-Depth Information
Knoten
{abstract}
Client
«use»
+ operation()
+ hinzufuegen(Knoten)
+ entfernen(Knoten)
+ gibKindKnoten():Knoten[]
*
Blatt
+ operation()
Kompositum
+ operation()
+ hinzufuegen(Knoten)
+ entfernen(Knoten)
+ gibKindKnoten():Knoten[]
Bild 4-20 Klassendiagramm Kompositum
Wenn der Client nicht wissen soll, ob ein Objekt ein Blatt oder ein Kompositum ist,
müssen beide Objekte dieselbe Schnittstelle haben. Die Implementierungen der Ope-
ration operation() können jedoch bei den verschiedenen Klassen voneinander ab-
weichen.
Ein Client kann sowohl für ein Blatt als auch für ein Kompositum eine Kindoperation
wie z. B. gibKindKnoten() aufrufen. Er soll ja nicht wissen, um was es sich bei ei-
nem Element handelt. Deshalb müssen die Operationen hinzufuegen() , entfer-
nen() und gibKindKnoten() in der Wurzel der Klassenhierarchie bei der Kompo-
nente definiert werden. Es ist sinnvoll, in der Wurzelklasse Knoten ein Defaultverhal-
ten für diese Kindoperationen zu implementieren, das für Blatt-Klassen geeignet ist
und das von einer Kompositum-Klasse überschrieben wird.
Eine gängige Lösung ist, dass die abstrakte Klasse die Kindmethoden so implemen-
tiert, dass diese Methoden eine Exception werfen, wenn sie aufgerufen werden. Die
Blatt-Klasse überschreibt dieses Verhalten nicht und wirft also eine Exception, wenn
eine ihrer Kindmethoden aufgerufen wird. Die Kompositum-Klasse hingegen über-
schreibt die Kindmethoden in sinnvoller Weise und wirft dabei keine Exception. Dies
bedeutet, dass die Nachbedingung einer Kindmethode in der Kompositum-Klasse ver-
schärft wird, was den Vertrag einer Kindmethode nicht bricht.
Die Klassen Kompositum und Blatt sind im Bild 4-20 nur als Stellvertreter zu be-
trachten. In einer Baumstruktur kann es sowohl mehrere Kompositum-Klassen als
auch mehrere Blatt-Klassen geben. Ein Beispiel für eine Baumstruktur mit mehreren
Blatt-Klassen ist in Kapitel 4.7.5 zu sehen.
Search WWH ::




Custom Search