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 Imperative Sprachkonzepte
3 Klassen und Objekte
4 Der Umgang mit Zeichenketten
5 Eigene Klassen schreiben
6 Exceptions
7 Äußere.innere Klassen
8 Besondere Klassen der Java SE
9 Generics<T>
10 Architektur, Design und angewandte Objektorientierung
11 Die Klassenbibliothek
12 Einführung in die nebenläufige Programmierung
13 Einführung in Datenstrukturen und Algorithmen
14 Einführung in grafische Oberflächen
15 Einführung in Dateien und Datenströme
16 Einführung in die <XML>-Verarbeitung mit Java
17 Einführung ins Datenbankmanagement mit JDBC
18 Bits und Bytes und Mathematisches
19 Die Werkzeuge des JDK
A Die Klassenbibliothek
Stichwort

Download:
- openbook, ca. 24,5 MB
- Aufgaben, ca. 1,1 MB
- Programme, ca. 12,8 MB
Buch bestellen
Ihre Meinung?

Spacer
Java ist auch eine Insel von Christian Ullenboom
Das umfassende Handbuch
Buch: Java ist auch eine Insel

Java ist auch eine Insel
Galileo Computing
1308 S., 10., aktualisierte Auflage, geb., mit DVD
ca. 49,90 Euro, ISBN 978-3-8362-1802-3
Pfeil5 Eigene Klassen schreiben
Pfeil5.1 Eigene Klassen mit Eigenschaften deklarieren
Pfeil5.1.1 Attribute deklarieren
Pfeil5.1.2 Methoden deklarieren
Pfeil5.1.3 Die this-Referenz
Pfeil5.2 Privatsphäre und Sichtbarkeit
Pfeil5.2.1 Für die Öffentlichkeit: public
Pfeil5.2.2 Kein Public Viewing – Passwörter sind privat
Pfeil5.2.3 Wieso nicht freie Methoden und Variablen für alle?
Pfeil5.2.4 Privat ist nicht ganz privat: Es kommt darauf an, wer’s sieht *
Pfeil5.2.5 Zugriffsmethoden für Attribute deklarieren
Pfeil5.2.6 Setter und Getter nach der JavaBeans-Spezifikation
Pfeil5.2.7 Paketsichtbar
Pfeil5.2.8 Zusammenfassung zur Sichtbarkeit
Pfeil5.3 Statische Methoden und statische Attribute
Pfeil5.3.1 Warum statische Eigenschaften sinnvoll sind
Pfeil5.3.2 Statische Eigenschaften mit static
Pfeil5.3.3 Statische Eigenschaften über Referenzen nutzen? *
Pfeil5.3.4 Warum die Groß- und Kleinschreibung wichtig ist *
Pfeil5.3.5 Statische Variablen zum Datenaustausch *
Pfeil5.3.6 Statische Eigenschaften und Objekteigenschaften *
Pfeil5.4 Konstanten und Aufzählungen
Pfeil5.4.1 Konstanten über öffentliche statische finale Variablen
Pfeil5.4.2 Typ(un)sichere Aufzählungen *
Pfeil5.4.3 Aufzählungen mit enum
Pfeil5.5 Objekte anlegen und zerstören
Pfeil5.5.1 Konstruktoren schreiben
Pfeil5.5.2 Der vorgegebene Konstruktor (default constructor)
Pfeil5.5.3 Parametrisierte und überladene Konstruktoren
Pfeil5.5.4 Copy-Konstruktor
Pfeil5.5.5 Einen anderen Konstruktor der gleichen Klasse mit this() aufrufen
Pfeil5.5.6 Ihr fehlt uns nicht – der Garbage-Collector
Pfeil5.5.7 Private Konstruktoren, Utility-Klassen, Singleton, Fabriken
Pfeil5.6 Klassen- und Objektinitialisierung *
Pfeil5.6.1 Initialisierung von Objektvariablen
Pfeil5.6.2 Statische Blöcke als Klasseninitialisierer
Pfeil5.6.3 Initialisierung von Klassenvariablen
Pfeil5.6.4 Eincompilierte Belegungen der Klassenvariablen
Pfeil5.6.5 Exemplarinitialisierer (Instanzinitialisierer)
Pfeil5.6.6 Finale Werte im Konstruktor und in statischen Blöcken setzen
Pfeil5.7 Assoziationen zwischen Objekten
Pfeil5.7.1 Unidirektionale 1:1-Beziehung
Pfeil5.7.2 Bidirektionale 1:1-Beziehungen
Pfeil5.7.3 Unidirektionale 1:n-Beziehung
Pfeil5.8 Vererbung
Pfeil5.8.1 Vererbung in Java
Pfeil5.8.2 Spielobjekte modellieren
Pfeil5.8.3 Die implizite Basisklasse java.lang.Object
Pfeil5.8.4 Einfach- und Mehrfachvererbung *
Pfeil5.8.5 Die Sichtbarkeit protected
Pfeil5.8.6 Konstruktoren in der Vererbung und super()
Pfeil5.9 Typen in Hierarchien
Pfeil5.9.1 Automatische und explizite Typanpassung
Pfeil5.9.2 Das Substitutionsprinzip
Pfeil5.9.3 Typen mit dem instanceof-Operator testen
Pfeil5.10 Methoden überschreiben
Pfeil5.10.1 Methoden in Unterklassen mit neuem Verhalten ausstatten
Pfeil5.10.2 Mit super an die Eltern
Pfeil5.10.3 Finale Klassen und finale Methoden
Pfeil5.10.4 Kovariante Rückgabetypen
Pfeil5.10.5 Array-Typen und Kovarianz *
Pfeil5.11 Drum prüfe, wer sich ewig dynamisch bindet
Pfeil5.11.1 Gebunden an toString()
Pfeil5.11.2 Implementierung von System.out.println(Object)
Pfeil5.11.3 Nicht dynamisch gebunden bei privaten, statischen und finalen Methoden
Pfeil5.11.4 Dynamisch gebunden auch bei Konstruktoraufrufen *
Pfeil5.11.5 Eine letzte Spielerei mit Javas dynamischer Bindung und überschatteten Attributen *
Pfeil5.12 Abstrakte Klassen und abstrakte Methoden
Pfeil5.12.1 Abstrakte Klassen
Pfeil5.12.2 Abstrakte Methoden
Pfeil5.13 Schnittstellen
Pfeil5.13.1 Schnittstellen deklarieren
Pfeil5.13.2 Implementieren von Schnittstellen
Pfeil5.13.3 Markierungsschnittstellen *
Pfeil5.13.4 Ein Polymorphie-Beispiel mit Schnittstellen
Pfeil5.13.5 Die Mehrfachvererbung bei Schnittstellen *
Pfeil5.13.6 Keine Kollisionsgefahr bei Mehrfachvererbung *
Pfeil5.13.7 Erweitern von Interfaces – Subinterfaces
Pfeil5.13.8 Konstantendeklarationen bei Schnittstellen
Pfeil5.13.9 Initialisierung von Schnittstellenkonstanten *
Pfeil5.13.10 Abstrakte Klassen und Schnittstellen im Vergleich
Pfeil5.14 Zum Weiterlesen

Galileo Computing - Zum Seitenanfang

5.7 Assoziationen zwischen ObjektenZur nächsten Überschrift

Eine wichtige Eigenschaft objektorientierter Systeme ist der Austausch von Nachrichten untereinander. Dazu »kennt« ein Objekt andere Objekte 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 unterscheiden, ob nur eine Seite die andere kennt oder ob eine Navigation in beiden Richtungen möglich ist:

  • Eine unidirektionale Beziehung geht nur in eine Richtung (ein Fan kennt seine Band, aber nicht umgekehrt).
  • 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.

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.


Galileo Computing - Zum Seitenanfang

5.7.1 Unidirektionale 1:1-BeziehungZur 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 sähe das in etwa so aus:

Listing 5.47: com/tutego/insel/game/va/Player.java, Player

public class Player
{
public Room room;
}

Listing 5.48: com/tutego/insel/game/va/Room.java, Room

public class Room
{
}

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

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

Player buster = new Player();
Room tower = new Room();
buster.room
= tower; // Buster kommt in den Tower

Assoziationen in der UML

Die UML stellt Assoziationen durch eine Linie zwischen den beteiligten Klassen dar. Hat eine Assoziation eine Richtung, zeigt ein Pfeil am Ende der Assoziation diese an. Wenn es keine Pfeile gibt, heißt das nur, dass die Richtung noch nicht genauer spezifiziert ist, und nicht automatisch, dass die Beziehung bidirektional ist.

Abbildung

Abbildung 5.20: Gerichtete Assoziation im UML-Diagramm

Die Multiplizität wird angeben als »untere Grenze..obere Grenze«, etwa 1..4. Außerdem lässt sich in UML über 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 Assoziationen 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

5.7.2 Bidirektionale 1:1-BeziehungenZur 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 5.50: com/tutego/insel/game/vb/Player.java, Player

public class Player
{
public Room room;
}

Listing 5.51: com/tutego/insel/game/vb/Room.java, Room

public class Room
{
public Player player;
}
Abbildung

Abbildung 5.21: Bei bidirektionalen Beziehungen gibt es im UML-Diagramm zwei Pfeile.

Verbinden wir das:

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

Player buster = new Player();
Room tower = new Room();
buster.room
= tower;
tower.player = buster;

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:

buster.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 von der Modellierung her nur genau einen Raum:

Listing 5.53: com/tutego/insel/game/vb/InvalidPlayground.java, main()

Player buster = new Player();
Room tower = new Room();
buster.room = tower;
tower.player = buster;

Room toilet = new Room();
toilet.player = buster;

System.out.println( buster ); // com.tutego.insel.game.vb.Player@aaaaaa
System.out.println( tower ); // com.tutego.insel.game.vb.Room@444444
System.out.println( toilet ); // com.tutego.insel.game.vb.Room@999999
System.out.println( buster.room ); // com.tutego.insel.game.vb.Room@444444
System.out.println( tower.player ); // com.tutego.insel.game.vb.Player@aaaaaa
System.out.println( toilet.player ); // com.tutego.insel.game.vb.Player@aaaaaa

An der Ausgabe ist abzulesen, dass sich Buster im Tower befindet, aber auch die Toilette sagt, dass Buster dort ist (die Kennungen hinter @ sind für das Buch durch gut unterscheidbare Zeichenketten ersetzt worden. Sie sind bei jedem Aufruf anders).

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

5.7.3 Unidirektionale 1:n-BeziehungZur nächsten ÜberschriftZur 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 beispielsweise nur eine feste Anzahl von Tasten und ein Tisch nur eine feste Anzahl von Beinen. 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ühevoll 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 in Kapitel 13, »Einführung in Datenstrukturen und Algorithmen«, mit besagten Datenstrukturen und Algorithmen beschäftigen, doch seien an dieser Stelle schon drei Methoden 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 der Elemente in 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 5.54: com/tutego/insel/game/vc/Player.java, Player

public class Player
{
public 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 besagen, dass die ArrayList nur Player aufnehmen wird und keine anderen Dinge (wie Geister). Die Raum-Klasse wird dann zu:

Listing 5.55: com/tutego/insel/game/vc/Room.java, Room

import java.util.ArrayList;

public class Room
{
private ArrayList<Player> players = new ArrayList<Player>();

public void addPlayer( Player player )
{
players.add( player );
}

public void listPlayers()
{
for ( Player player : players )
System.out.println( player.name );
}
}
Abbildung

Abbildung 5.22: Room referenziert Player

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 5.56: com/tutego/insel/game/vc/Playground.java, main()

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


Ihr Kommentar

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







<< zurück
  Zum Katalog
Zum Katalog: Java ist auch eine Insel





Java ist auch eine Insel
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Java 7 – Mehr als eine Insel





 Java 7 –
 Mehr als eine Insel


Zum Katalog: Android 3






 Android 3


Zum Katalog: Android-Apps entwickeln






 Android-Apps
 entwickeln


Zum Katalog: NetBeans Platform 7






 NetBeans
 Platform 7


Zum Katalog: Einstieg in Eclipse 3.7






 Einstieg in
 Eclipse 3.7


Zum Katalog: Einstieg in Java






 Einstieg
 in Java


Zum Katalog: Einstieg in Java 7






 Einstieg in
 Java 7


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2011
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