6.2 Assoziationen zwischen Objekten
 
Eine wichtige Eigenschaft objektorientierter Systeme ist der Austausch von Nachrichten untereinander. Dazu »kennt« ein Objekt ein anderes und bittet dieses, etwas zu unternehmen. Dieses Kennen nennt sich Assoziation und ist vielleicht das wichtigste Werkzeug bei der Bildung von Objektverbänden.
Wir können uns etwa vorstellen, dass eine Disko einen Verweis auf einen DJ besitzt. Dann sind Disko und DJ zwei Objekte, die sich kennen. Gehen wir einfach davon aus, dass die Disko den DJ kennt, aber der DJ seine Disko nicht. In Java würde das in etwa so aussehen:
class Disko
{
DJ dj;
}
class DJ
{
String name;
}
Zur Laufzeit müssen natürlich noch die Verweise gesetzt werden.
DJ djSwing = new DJ();
djSwing.name = "Detlef Jonas Hausmaister";
Disko ü30 = new Disko();
ü30.dj = djSwing;
Assoziationen in der UML
In der UML gibt es für Assoziationen ebenfalls eine grafische Darstellung. Die beiden Klassen sind durch eine Linie verbunden. Da jede Assoziation eine Richtung hat, lässt sich auch ein Pfeil am Ende der Assoziation anbringen, wenn die Assoziation einseitig ist, wie in unserem Fall. In der Regel tauchen die Namen der Assoziation, wie in der UML-Grafik zu sehen, nicht als Variablennamen auf.
 Hier klicken, um das Bild zu Vergrößern
Abbildung 6.2
Eine gerichtete Beziehung
Herausforderungen bei der Umsetzung UML in Java
Diese gerichteten Assoziationen sind in Java sehr einfach umzusetzen, wie wir im Beispiel gesehen haben. Beidseitige Assoziationen erfordern schon etwas mehr Programmieraufwand, da sichergestellt sein muss, dass beide Seiten eine gültige Referenz besitzen. Denn wird die Assoziation auf einer Seite aufgekündigt, etwa durch Setzen der Referenz auf null, muss auch die andere Seite die Referenz lösen. Am besten erfolgt dies mit Zugriffsmethoden, etwa wie setzeDJ(), löscheDJ() bei der Disko und setzeDisko() und löscheDisko() beim Disc-Jockey. Hinzu kommt, dass die Disko sicherlich nicht nur einen DJ unter Vertrag hat, sondern mehrere. Daher findet sich auf der Seite der Disko eine Datenstruktur – wie java.util.ArrayList –, die alle aktiven DJs speichert.
6.2.1 Gegenseitige Abhängigkeiten von Klassen
 
In Java brauchen wir uns keine Gedanken um die Reihenfolge der Deklarationen zu machen. Wo es in anderen Sprachen genau auf die Reihenfolge ankommt, kann in Java eine Klasse eine andere benutzen, auch wenn diese erst später im Programmtext definiert ist. In C ist dies ein bekanntes Problemfeld: Wir wollen eine Funktion nutzen, müssen diese aber vor dem Aufruf schon definiert haben.1
In Java können wir uns ganz und gar auf den Compiler verlassen – es ist seine Aufgabe, mit den Abhängigkeiten zurechtzukommen. Nehmen wir zum Beispiel die Beziehung Disko und DJ. Definieren wir die Disko-Klasse zuerst, kann der DJ sie nutzen. Dann kennt der DJ aber noch keine Disko! Dieses Problem ist glücklicherweise nur in C oder C++ problematisch. In Java hilft uns der Compiler, der während des Compile-Vorgangs eine Vorausschau in den Dateien der importierten Pakete und in den eigenen Dateien unternimmt. Die zyklische Abhängigkeit zwischen Disko und DJ ist völlig unproblematisch.
1 Oder mit extern oder Prototypen diese Definition vorziehen.
|