Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Java ist auch eine Sprache
2 Sprachbeschreibung
3 Klassen und Objekte
4 Der Umgang mit Zeichenketten
5 Mathematisches
6 Eigene Klassen schreiben
7 Angewandte Objektorientierung
8 Exceptions
9 Die Funktionsbibliothek
10 Threads und nebenläufige Programmierung
11 Raum und Zeit
12 Datenstrukturen und Algorithmen
13 Dateien und Datenströme
14 Die eXtensible Markup Language (XML)
15 Grafische Oberflächen mit Swing
16 Grafikprogrammierung
17 Netzwerkprogrammierung
18 Verteilte Programmierung mit RMI und Web-Services
19 JavaServer Pages und Servlets
20 Applets
21 Midlets und die Java ME
22 Datenbankmanagement mit JDBC
23 Reflection und Annotationen
24 Logging und Monitoring
25 Sicherheitskonzepte
26 Java Native Interface (JNI)
27 Dienstprogramme für die Java-Umgebung
A Die Begleit-DVD
Stichwort

Download:
- ZIP, ca. 12,5 MB
Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Java ist auch eine Insel von Christian Ullenboom
Programmieren mit der Java Standard Edition Version 6
Buch: Java ist auch eine Insel

Java ist auch eine Insel
7., aktualisierte Auflage
geb., mit DVD (November 2007)
1.492 S., 49,90 Euro
Galileo Computing
ISBN 978-3-8362-1146-8
Pfeil 6 Eigene Klassen schreiben
Pfeil 6.1 Eigene Klassen mit Eigenschaften deklarieren
Pfeil 6.1.1 Attribute deklarieren
Pfeil 6.1.2 Methoden deklarieren
Pfeil 6.1.3 Die this-Referenz
Pfeil 6.2 Privatsphäre und Sichtbarkeit
Pfeil 6.2.1 Für die Öffentlichkeit: public
Pfeil 6.2.2 Paketsichtbar
Pfeil 6.2.3 Kein Public Viewing – Passwörter sind privat
Pfeil 6.2.4 Wieso nicht freie Methoden und Variablen für alle?
Pfeil 6.2.5 Privat ist nicht ganz privat: Es kommt darauf an, wer’s sieht
Pfeil 6.2.6 Zugriffsmethoden für Attribute deklarieren
Pfeil 6.2.7 Setter und Getter nach der JavaBeans-Spezifikation
Pfeil 6.3 Statische Methoden und statische Attribute
Pfeil 6.3.1 Warum statische Eigenschaften sinnvoll sind
Pfeil 6.3.2 Statische Eigenschaften mit static
Pfeil 6.3.3 Statische Eigenschaften über Referenzen nutzen?
Pfeil 6.3.4 Warum die Groß- und Kleinschreibung wichtig ist
Pfeil 6.3.5 Statische Eigenschaften und Objekteigenschaften
Pfeil 6.3.6 Statische Variablen zum Datenaustausch
Pfeil 6.3.7 Statische Blöcke als Klasseninitialisierer
Pfeil 6.4 Konstanten und Aufzählungen
Pfeil 6.4.1 Konstanten über öffentliche statische finale Variablen
Pfeil 6.4.2 Eincompilierte Belegungen der Klassenvariablen
Pfeil 6.4.3 Typ(un)sicherere Aufzählungen
Pfeil 6.4.4 Aufzählungen mit enum
Pfeil 6.5 Objekte anlegen und zerstören
Pfeil 6.5.1 Konstruktoren schreiben
Pfeil 6.5.2 Der Standard-Konstruktor
Pfeil 6.5.3 Parametrisierte und überladene Konstruktoren
Pfeil 6.5.4 Konstruktor nimmt ein Objekt vom eigenen Typ an (Copy-Konstruktor)
Pfeil 6.5.5 Einen anderen Konstruktor der gleichen Klasse aufrufen
Pfeil 6.5.6 Initialisierung der Objekt- und Klassenvariablen
Pfeil 6.5.7 Finale Werte im Konstruktor und in statischen Blöcken setzen
Pfeil 6.5.8 Exemplarinitialisierer (Instanzinitialisierer)
Pfeil 6.5.9 Ihr fehlt uns nicht – der Garbage-Collector
Pfeil 6.5.10 Implizit erzeugte String-Objekte
Pfeil 6.5.11 Private Konstruktoren, Utility-Klassen, Singleton, Fabriken
Pfeil 6.6 Assoziationen zwischen Objekten
Pfeil 6.6.1 Unidirektionale 1:1-Beziehung
Pfeil 6.6.2 Bidirektionale 1:1-Beziehungen
Pfeil 6.6.3 Unidirektionale 1:n-Beziehung
Pfeil 6.7 Vererbung
Pfeil 6.7.1 Vererbung in Java
Pfeil 6.7.2 Spielobjekte modelliert
Pfeil 6.7.3 Einfach- und Mehrfachvererbung
Pfeil 6.7.4 Sichtbarkeit protected
Pfeil 6.7.5 Konstruktoren in der Vererbung und super
Pfeil 6.7.6 Automatische und explizite Typanpassung
Pfeil 6.7.7 Das Substitutionsprinzip
Pfeil 6.7.8 Typen mit dem binären Operator instanceof testen
Pfeil 6.7.9 Methoden überschreiben
Pfeil 6.7.10 Mit super an die Eltern
Pfeil 6.7.11 Kovariante Rückgabetypen
Pfeil 6.7.12 Array-Typen und Kovarianz
Pfeil 6.7.13 Zusammenfassung zur Sichtbarkeit
Pfeil 6.8 Dynamisches Binden
Pfeil 6.8.1 Unpolymorph bei privaten, statischen und finalen Methoden
Pfeil 6.8.2 Polymorphie bei Konstruktoraufrufen
Pfeil 6.8.3 Finale Klassen
Pfeil 6.8.4 Nicht überschreibbare (finale) Methoden
Pfeil 6.9 Abstrakte Klassen und abstrakte Methoden
Pfeil 6.9.1 Abstrakte Klassen
Pfeil 6.9.2 Abstrakte Methoden
Pfeil 6.10 Schnittstellen
Pfeil 6.10.1 Deklarieren von Schnittstellen
Pfeil 6.10.2 Implementieren von Schnittstellen
Pfeil 6.10.3 Markierungsschnittstellen
Pfeil 6.10.4 Ein Polymorphie-Beispiel mit Schnittstellen
Pfeil 6.10.5 Die Mehrfachvererbung bei Schnittstellen
Pfeil 6.10.6 Keine Kollisionsgefahr bei Mehrfachvererbung
Pfeil 6.10.7 Erweitern von Interfaces – Subinterfaces
Pfeil 6.10.8 Vererbte Konstanten bei Schnittstellen
Pfeil 6.10.9 Schnittstellenmethoden, die nicht implementiert werden müssen
Pfeil 6.10.10 Abstrakte Klassen und Schnittstellen im Vergleich
Pfeil 6.11 Geschachtelte (innere) Klassen, Schnittstellen, Aufzählungen
Pfeil 6.11.1 Statische innere Klassen und Schnittstellen
Pfeil 6.11.2 Mitglieds- oder Elementklassen
Pfeil 6.11.3 Lokale Klassen
Pfeil 6.11.4 Anonyme innere Klassen
Pfeil 6.11.5 this und Vererbung
Pfeil 6.12 Generische Datentypen
Pfeil 6.12.1 Einfache Klassenschablonen
Pfeil 6.12.2 Einfache Methodenschablonen
Pfeil 6.12.3 Umsetzen der Generics, Typlöschung und Raw-Types
Pfeil 6.12.4 Einschränken der Typen
Pfeil 6.12.5 Generics und Vererbung, Invarianz
Pfeil 6.12.6 Wildcards
Pfeil 6.13 Die Spezial-Oberklasse Enum
Pfeil 6.13.1 Methoden auf Enum-Objekten
Pfeil 6.13.2 enum mit eigenen Konstruktoren und Methoden
Pfeil 6.14 Dokumentationskommentare mit JavaDoc
Pfeil 6.14.1 Einen Dokumentationskommentar setzen
Pfeil 6.14.2 Mit javadoc eine Dokumentation erstellen
Pfeil 6.14.3 HTML-Tags in Dokumentationskommentaren
Pfeil 6.14.4 Generierte Dateien
Pfeil 6.14.5 Dokumentationskommentare im Überblick
Pfeil 6.14.6 JavaDoc und Doclets
Pfeil 6.14.7 Veraltete (deprecated) Klassen, Konstruktoren und Methoden


Galileo Computing - Zum Seitenanfang

6.6 Assoziationen zwischen Objekten Zur nächsten ÜberschriftZur vorigen Überschrift

Eine wichtige Eigenschaft objektorientierter Systeme ist der Austausch von Nachrichten untereinander. Dazu »kennt« ein Objekt andere und kann Anforderungen weitergeben. Diese Verbindung nennt sich Assoziation und ist das wichtigste Werkzeug bei der Bildung von Objektverbänden.

Assoziationstypen

Bei Assoziationen ist zu unterschieden, ob nur eine Seite die andere kennt, oder ob eine Navigation in beiden Richtungen möglich ist.

  • Eine bidirektionale Beziehung geht in beide Richtungen (Raum kennt Spieler und Spieler kennt Raum). Eine bidirektionale Beziehung ist natürlich ein großer Vorteil, da die Anwendung die Assoziation in beliebiger Richtung ablaufen kann.
  • Eine unidirektionale Beziehung geht nur in eine Richtung (ein Fan kennt seine Band, aber nicht umgekehrt).

Daneben gibt es bei Beziehungen die Multiplizität – auch Kardinalität genannt. Sie sagt aus, mit wie vielen Objekten eine Seite eine Beziehung haben kann. Übliche Beziehungen sind 1:1 und 1:n.

Assoziationen in der UML

Die UML stellt für Assoziationen durch eine Linie zwischen den beteiligten Klassen dar. Hat eine Assoziation eine Richtung, lässt sich ein Pfeil am Ende der Assoziation anbringen. Die Multiplizität wird angeben als »untere Grenze..obere Grenze«, etwa 1..4. Außerdem lässt sich in UML eine Rolle angeben, welche Aufgabe die Beziehung für eine Seite hat. Die Rollen sind wichtig für reflexive Assoziationen (auch zirkuläre oder rekursive Assoziation genannt), wenn ein Typ auf sich selbst zeigt. Ein beliebtes Beispiel ist der Typ Person mit den Rollen Chef und Mitarbeiter.


Galileo Computing - Zum Seitenanfang

6.6.1 Unidirektionale 1:1-Beziehung Zur nächsten ÜberschriftZur vorigen Überschrift

Damit ein Spieler sich in einem Raum befinden kann, lässt sich in Player eine Referenzvariable vom Typ Room anlegen. In Java würde das in etwa so aussehen:

Listing 6.42 com/tutego/insel/game/va/Player.java, Player

class Player 
{ 
  Room room; 
}

Listing 6.43 com/tutego/insel/game/va/Room.java, Room

class Room 
{ 
}

Zur Laufzeit müssen natürlich noch die Verweise gesetzt werden:

Listing 6.44 com/tutego/insel/game/va/Playground.java, main()

Player p = new Player(); 
Room   r = new Room(); 
p.room = r;

Galileo Computing - Zum Seitenanfang

6.6.2 Bidirektionale 1:1-Beziehungen Zur nächsten ÜberschriftZur vorigen Überschrift

Diese gerichteten Assoziationen sind in Java sehr einfach umzusetzen, wie wir im Beispiel gesehen haben. Beidseitige Assoziationen erscheinen auf den ersten Blick auch einfach, da nur die Gegenseite um eine Verweisvariable erweitert werden muss. Beginnen wir mit dem Szenario, dass der Spieler seinen Raum und der Raum seinen Spieler kennen soll.

Listing 6.45 com/tutego/insel/game/vb/Player.java, Player

class Player 
{ 
  Room room; 
}

Listing 6.46 com/tutego/insel/game/vb/Room.java, Room

class Room 
{ 
  Player player; 
}

Verbinden wir das:

Listing 6.47 com/tutego/insel/game/vb/Playground.java, main()

Player p = new Player(); 
Room   r = new Room(); 
p.room   = r; 
r.player = p;

So einfach ist es aber nicht! Bidirektionale Beziehungen erfordern 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.

p.room = null;   // Spieler will nicht mehr im Raum sein

Auch kann es passieren, dass zwei Räume angeben, einen Spieler zu besitzen, doch der Spieler kennt nur genau einen Raum.

Player pl = new Player(); 
Room   r1 = new Room(); 
pl.room   = r1; 
r1.player = pl; 
Room r2 = new Room(); 
r2.player = pl;

Die Wurzel des Übels liegt in den Variablen. Variablen können keine Konsistenzbedingungen aufrechterhalten, Methoden können wie in einer Transaktion aber mehrere Operationen durchführen und von einem korrekten Zustand in den nächsten überführen. Daher erfolgt diese Kontrolle am besten mit Zugriffsmethoden, etwa wie setRoom() und setPlayer().


Galileo Computing - Zum Seitenanfang

6.6.3 Unidirektionale 1:n-Beziehung topZur vorigen Überschrift

Immer dann, wenn ein Objekt mehrere andere Objekte referenzieren muss, reicht eine einfache Referenzvariable vom Typ der anderen Seite nicht mehr aus. Dann sind Datenstrukturen gefragt, die mehrere Referenzen aufnehmen können, etwa dann, wenn sich in einem Raum mehrere Spieler befinden können, oder wenn ein Spieler mehrere Gegenstände mit sich trägt. Wir müssen auf der 1-Seite eine Datenstruktur verwenden, die entweder eine feste oder eine dynamische Anzahl anderer Objekte aufnimmt. Eine Handy-Tastatur hat etwa nur eine feste Anzahl Tasten und ein Tisch nur eine feste Anzahl Beine. Bei Sammlungen dieser Art ist ein Array gut geeignet. Bei anderen Beziehungen, wo die Anzahl referenzierter Objekte dynamisch ist, ist ein Array wenig elegant, da die manuellen Vergrößerungen oder Verkleinerungen mühvoll sind.

Dynamische Datenstruktur ArrayList

Wollen wir zum Beispiel erlauben, dass ein Spieler mehrere Gegenstände tragen kann oder eine unbekannte Anzahl Spieler sich in einem Raum befinden können, ist eine dynamische Datenstruktur wie java.util.ArrayList sinnvoller. Genauer wollen wir uns zwar erst im Kapitel 12 mit Datenstrukturen und Algorithmen beschäftigen, doch seien an dieser Stelle schon drei Funktionen der ArrayList vorgestellt, die Elemente in einer Liste (Sequenz) hält:

  • boolean add(E o). Fügt ein Objekt vom Typ E der Liste hinzu.
  • int size(). Liefert die Anzahl Elemente der Liste
  • E get(int index). Liefert das Element an der Stelle index.

Mit diesem Wissen wollen wir dem Raum Methoden geben, sodass er beliebig viele Spieler aufnehmen kann. Für den unidirektionalen Fall ist die Player-Klasse wieder einfach:

Listing 6.48 com/tutego/insel/game/vc/Player.java, Player

class Player 
{ 
  String name; 
 
  public Player( String name ) 
  { 
    this.name = name; 
  } 
}

Der Raum bekommt ein internes Attribut players, vom Typ der ArrayList:

private ArrayList<Player> players = new ArrayList<Player>();

Dass Angaben in spitzen Klammern hinter dem Typ stehen, liegt an den Java Generics – sie sagen, dass die ArrayList nur Player aufnehmen wird und keine anderen Dinge, wie Geister. Die Raum-Klasse wird dann zu:

Listing 6.49 com/tutego/insel/game/vc/Room.java, Room

import java.util.ArrayList; 
 
class Room 
{ 
  private ArrayList<Player> players = new ArrayList<Player>(); 
 
  void addPlayer( Player p ) 
  { 
    players.add( p ); 
  } 
 
  void listPlayers() 
  { 
    for ( Player player : players ) 
      System.out.println( player.name ); 
  } 
}

Die Datenstruktur selbst ist privat, und die addPlayer()-Methode fügt einen Spieler in die ArrayList ein. Eine Besonderheit bietet die Methode listPlayers(), denn sie nutzt das erweiterte for zum Durchlaufen aller Spieler. Beim erweiterten for ist rechts vom Doppelpunkt nicht nur ein Array erlaubt, sondern auch eine Datenstruktur wie die Liste. Nachdem also zwei Spieler mit addPlayer() hinzugefügt wurden, wird listPlayers() die beiden Spielernamen ausgeben:

Listing 6.50 com/tutego/insel/game/vc/Playground.java, main()

Room room = new Room(); 
room.addPlayer( new Player( "Tim" ) ); 
room.addPlayer( new Player( "Jorry" ) ); 
room.listPlayers();                      // Tim Jorry


Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.






<< zurück



Copyright © Galileo Press 2008
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de