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 Generics, innere Klassen
10 Die Klassenbibliothek
11 Threads und nebenläufige Programmierung
12 Datenstrukturen und Algorithmen
13 Raum und Zeit
14 Dateien und Datenströme
15 Die eXtensible Markup Language (XML)
16 Grafische Oberflächen mit Swing
17 Grafikprogrammierung
18 Netzwerkprogrammierung
19 Verteilte Programmierung mit RMI und Web–Services
20 JavaServer Pages und Servlets
21 Applets
22 Midlets und die Java ME
23 Datenbankmanagement mit JDBC
24 Reflection und Annotationen
25 Logging und Monitoring
26 Sicherheitskonzepte
27 Java Native Interface (JNI)
28 Dienstprogramme für die Java-Umgebung
Stichwort
Download: - ZIP, ca. 14,1 MB
Buch bestellen
Ihre Meinung?
<< zurück | Galileo Computing / <openbook> / Java-Insel | vor >>
Java ist auch eine Insel (8. Auflage) von Christian Ullenboom Programmieren mit der Java Standard Edition Version 6
Java ist auch eine Insel (8. Aufl.) 8., aktual. Auflage, geb., mit DVD 1.475 S., 49,90 Euro Galileo Computing ISBN 978-3-8362-1371-4 |
| 6 Eigene Klassen schreiben
|  | 6.1 Eigene Klassen mit Eigenschaften deklarieren
|  |  | 6.1.1 Attribute deklarieren
|  |  | 6.1.2 Methoden deklarieren
|  |  | 6.1.3 Die this-Referenz
|  | 6.2 Privatsphäre und Sichtbarkeit
|  |  | 6.2.1 Für die Öffentlichkeit: public
|  |  | 6.2.2 Kein Public Viewing – Passwörter sind privat
|  |  | 6.2.3 Wieso nicht freie Methoden und Variablen für alle?
|  |  | 6.2.4 Privat ist nicht ganz privat: Es kommt darauf an, wer’s sieht
|  |  | 6.2.5 Zugriffsmethoden für Attribute deklarieren
|  |  | 6.2.6 Setter und Getter nach der JavaBeans-Spezifikation
|  |  | 6.2.7 Paketsichtbar
|  |  | 6.2.8 Zusammenfassung zur Sichtbarkeit
|  | 6.3 Statische Methoden und statische Attribute
|  |  | 6.3.1 Warum statische Eigenschaften sinnvoll sind
|  |  | 6.3.2 Statische Eigenschaften mit static
|  |  | 6.3.3 Statische Eigenschaften über Referenzen nutzen?
|  |  | 6.3.4 Warum die Groß- und Kleinschreibung wichtig ist
|  |  | 6.3.5 Statische Variablen zum Datenaustausch
|  |  | 6.3.6 Statische Eigenschaften und Objekteigenschaften
|  | 6.4 Konstanten und Aufzählungen
|  |  | 6.4.1 Konstanten über öffentliche statische finale Variablen
|  |  | 6.4.2 Eincompilierte Belegungen der Klassenvariablen
|  |  | 6.4.3 Typ(un)sichere Aufzählungen
|  |  | 6.4.4 Aufzählungen mit enum
|  | 6.5 Objekte anlegen und zerstören
|  |  | 6.5.1 Konstruktoren schreiben
|  |  | 6.5.2 Der Default-Konstruktor
|  |  | 6.5.3 Parametrisierte und überladene Konstruktoren
|  |  | 6.5.4 Copy-Konstruktor
|  |  | 6.5.5 Einen anderen Konstruktor der gleichen Klasse aufrufen
|  |  | 6.5.6 Ihr fehlt uns nicht – der Garbage-Collector
|  |  | 6.5.7 Private Konstruktoren, Utility-Klassen, Singleton, Fabriken
|  | 6.6 Klassen- und Objektinitialisierung
|  |  | 6.6.1 Initialisierung von Objektvariablen
|  |  | 6.6.2 Statische Blöcke als Klasseninitialisierer
|  |  | 6.6.3 Initialisierung von Klassenvariablen
|  |  | 6.6.4 Exemplarinitialisierer (Instanzinitialisierer)
|  |  | 6.6.5 Finale Werte im Konstruktor und in statischen Blöcken setzen
|  | 6.7 Assoziationen zwischen Objekten
|  |  | 6.7.1 Unidirektionale 1:1-Beziehung
|  |  | 6.7.2 Bidirektionale 1:1-Beziehungen
|  |  | 6.7.3 Unidirektionale 1:n-Beziehung
|  | 6.8 Vererbung
|  |  | 6.8.1 Vererbung in Java
|  |  | 6.8.2 Spielobjekte modelliert
|  |  | 6.8.3 Implizite Basisklasse java.lang.Object
|  |  | 6.8.4 Einfach- und Mehrfachvererbung
|  |  | 6.8.5 Sichtbarkeit protected
|  |  | 6.8.6 Konstruktoren in der Vererbung und super
|  | 6.9 Typen in Hierarchien
|  |  | 6.9.1 Automatische und explizite Typanpassung
|  |  | 6.9.2 Das Substitutionsprinzip
|  |  | 6.9.3 Typen mit dem binären Operator instanceof testen
|  | 6.10 Methoden überschreiben
|  |  | 6.10.1 Methoden in Unterklassen mit neuem Verhalten ausstatten
|  |  | 6.10.2 Mit super an die Eltern
|  |  | 6.10.3 Finale Klassen und finale Methoden
|  |  | 6.10.4 Kovariante Rückgabetypen
|  |  | 6.10.5 Array-Typen und Kovarianz
|  | 6.11 Dynamisches Binden/Polymorphie
|  |  | 6.11.1 Unpolymorph bei privaten, statischen und finalen Methoden
|  |  | 6.11.2 Polymorphie bei Konstruktoraufrufen
|  | 6.12 Abstrakte Klassen und abstrakte Methoden
|  |  | 6.12.1 Abstrakte Klassen
|  |  | 6.12.2 Abstrakte Methoden
|  | 6.13 Schnittstellen
|  |  | 6.13.1 Deklarieren von Schnittstellen
|  |  | 6.13.2 Implementieren von Schnittstellen
|  |  | 6.13.3 Markierungsschnittstellen
|  |  | 6.13.4 Ein Polymorphie-Beispiel mit Schnittstellen
|  |  | 6.13.5 Die Mehrfachvererbung bei Schnittstellen
|  |  | 6.13.6 Keine Kollisionsgefahr bei Mehrfachvererbung
|  |  | 6.13.7 Erweitern von Interfaces – Subinterfaces
|  |  | 6.13.8 Vererbte Konstanten bei Schnittstellen
|  |  | 6.13.9 Abstrakte Klassen und Schnittstellen im Vergleich
|  | 6.14 Dokumentationskommentare mit JavaDoc
|  |  | 6.14.1 Einen Dokumentationskommentar setzen
|  |  | 6.14.2 Mit javadoc eine Dokumentation erstellen
|  |  | 6.14.3 HTML-Tags in Dokumentationskommentaren
|  |  | 6.14.4 Generierte Dateien
|  |  | 6.14.5 Dokumentationskommentare im Überblick
|  |  | 6.14.6 JavaDoc und Doclets
|  |  | 6.14.7 Veraltete (deprecated) Typen und Eigenschaften
## 6.7 Assoziationen zwischen Objekten 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 unterschieden, 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. ### 6.7.1 Unidirektionale 1:1-Beziehung 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 6.43 com/tutego/insel/game/va/Player.java, Player
    public class Player
    {
      public Room room;
    }
Listing 6.44 com/tutego/insel/game/va/Room.java, Room
    public class Room
    {
    }
Zur Laufzeit müssen natürlich noch die Verweise gesetzt werden: Listing 6.45 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 für 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. Hier klicken, um das Bild zu vergrößern 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. ### 6.7.2 Bidirektionale 1:1-Beziehungen 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.46 com/tutego/insel/game/vb/Player.java, Player
    public class Player
    {
      public Room room;
    }
Listing 6.47 com/tutego/insel/game/vb/Room.java, Room
    public class Room
    {
      public Player player;
    }
Hier klicken, um das Bild zu vergrößern Abbildung 6.5 Bei bidirektionalen Beziehungen gibt es zwei Pfeile. Verbinden wir das: Listing 6.48 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 6.49 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 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(). ### 6.7.3 Unidirektionale 1:n-Beziehung 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ü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 12 mit 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 Elemente der Liste. 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.50 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 sagen, dass die ArrayList nur Player aufnehmen wird und keine anderen Dinge, wie Geister. Die Raum-Klasse wird dann zu: Listing 6.51 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 );
      }
    }
Hier klicken, um das Bild zu vergrößern 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.52 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. >> Zum Feedback-Formular
<< zurück | <top> | vor >>
Zum Katalog
Java ist auch eine Insel Jetzt bestellen
Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen? Ihre Meinung
Tipp
| Coding for Fun
Buchempfehlungen
| Objektorientierte Programmierung
| Einstieg in Eclipse 3.4
| Java 6 lernen mit Eclipse
| NetBeans Platform 6
| Java und XML
| Visual C# 2008
| IT-Handbuch für Fachinformatiker
| C++ von A bis Z
Shopping
Versandkostenfrei bestellen in Deutschland und Österreich Info

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