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 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?

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

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
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 Kein Public Viewing – Passwörter sind privat
Pfeil 6.2.3 Wieso nicht freie Methoden und Variablen für alle?
Pfeil 6.2.4 Privat ist nicht ganz privat: Es kommt darauf an, wer’s sieht
Pfeil 6.2.5 Zugriffsmethoden für Attribute deklarieren
Pfeil 6.2.6 Setter und Getter nach der JavaBeans-Spezifikation
Pfeil 6.2.7 Paketsichtbar
Pfeil 6.2.8 Zusammenfassung zur Sichtbarkeit
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 Variablen zum Datenaustausch
Pfeil 6.3.6 Statische Eigenschaften und Objekteigenschaften
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)sichere 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 Default-Konstruktor
Pfeil 6.5.3 Parametrisierte und überladene Konstruktoren
Pfeil 6.5.4 Copy-Konstruktor
Pfeil 6.5.5 Einen anderen Konstruktor der gleichen Klasse aufrufen
Pfeil 6.5.6 Ihr fehlt uns nicht – der Garbage-Collector
Pfeil 6.5.7 Private Konstruktoren, Utility-Klassen, Singleton, Fabriken
Pfeil 6.6 Klassen- und Objektinitialisierung
Pfeil 6.6.1 Initialisierung von Objektvariablen
Pfeil 6.6.2 Statische Blöcke als Klasseninitialisierer
Pfeil 6.6.3 Initialisierung von Klassenvariablen
Pfeil 6.6.4 Exemplarinitialisierer (Instanzinitialisierer)
Pfeil 6.6.5 Finale Werte im Konstruktor und in statischen Blöcken setzen
Pfeil 6.7 Assoziationen zwischen Objekten
Pfeil 6.7.1 Unidirektionale 1:1-Beziehung
Pfeil 6.7.2 Bidirektionale 1:1-Beziehungen
Pfeil 6.7.3 Unidirektionale 1:n-Beziehung
Pfeil 6.8 Vererbung
Pfeil 6.8.1 Vererbung in Java
Pfeil 6.8.2 Spielobjekte modelliert
Pfeil 6.8.3 Implizite Basisklasse java.lang.Object
Pfeil 6.8.4 Einfach- und Mehrfachvererbung
Pfeil 6.8.5 Sichtbarkeit protected
Pfeil 6.8.6 Konstruktoren in der Vererbung und super
Pfeil 6.9 Typen in Hierarchien
Pfeil 6.9.1 Automatische und explizite Typanpassung
Pfeil 6.9.2 Das Substitutionsprinzip
Pfeil 6.9.3 Typen mit dem binären Operator instanceof testen
Pfeil 6.10 Methoden überschreiben
Pfeil 6.10.1 Methoden in Unterklassen mit neuem Verhalten ausstatten
Pfeil 6.10.2 Mit super an die Eltern
Pfeil 6.10.3 Finale Klassen und finale Methoden
Pfeil 6.10.4 Kovariante Rückgabetypen
Pfeil 6.10.5 Array-Typen und Kovarianz
Pfeil 6.11 Dynamisches Binden/Polymorphie
Pfeil 6.11.1 Unpolymorph bei privaten, statischen und finalen Methoden
Pfeil 6.11.2 Polymorphie bei Konstruktoraufrufen
Pfeil 6.12 Abstrakte Klassen und abstrakte Methoden
Pfeil 6.12.1 Abstrakte Klassen
Pfeil 6.12.2 Abstrakte Methoden
Pfeil 6.13 Schnittstellen
Pfeil 6.13.1 Deklarieren von Schnittstellen
Pfeil 6.13.2 Implementieren von Schnittstellen
Pfeil 6.13.3 Markierungsschnittstellen
Pfeil 6.13.4 Ein Polymorphie-Beispiel mit Schnittstellen
Pfeil 6.13.5 Die Mehrfachvererbung bei Schnittstellen
Pfeil 6.13.6 Keine Kollisionsgefahr bei Mehrfachvererbung
Pfeil 6.13.7 Erweitern von Interfaces – Subinterfaces
Pfeil 6.13.8 Vererbte Konstanten bei Schnittstellen
Pfeil 6.13.9 Abstrakte Klassen und Schnittstellen im Vergleich
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) Typen und Eigenschaften


Galileo Computing - Zum Seitenanfang

6.8 Vererbung Zur nächsten ÜberschriftZur vorigen Überschrift

Schon von Kindheit an lernen wir, Objekte in Beziehung zu setzen. Die Assoziationen bildet dabei die Hat-Beziehung zwischen Objekten ab: Ein Teddy hat (nach dem Kauf) zwei Arme, der Tisch hat vier Beine, der Wauwau hat ein Fell. Neben der Assoziation von Objekten gibt es eine weitere Form der Beziehung, die Ist-eine-Art-von-Beziehung [So etwas gibt es auch in der Linguistik; dort heißt der Oberbegriff eines Begriffs »Hyperonym« und der Unterbegriff eines Begriffs »Hyponym«.] . Ein Apfel und Birne sind Obstsorten, Lotad, Seedot und Wingull verschiedene Pokémons und Berg ist der Sammelbegriff und die Kategorie für K2 und Mount Everest.

Abbildung 6.6 Vererbung und Assoziation

Das Besondere bei der Ist-eine-Art-von-Beziehung ist die Tatsache, dass die Gruppe gewisse Merkmale für alle Elemente der Gruppe vorgibt [Semantische Netzwerke sind in der kognitiven Psychologie ein Erklärmodell zur Wissensrepräsentation. Eigenschaften gehören zu Kategorien, die durch Ist-eine-Art-von-Beziehungen hierarchisch verbunden sind. Informationen, die nicht bei einem speziellen Konzept abgespeichert sind, lassen sich von einem übergeordneten Konzept abrufen.] . Bei Obst haben wir eher eine intuitive Vorstellung, jeder Berg hat dagegen einen Höhe und einen Namen sowie eine Reihe von Besteigern.

Programmiersprachen drücken über Vererbung Gruppierung und Hierarchiebildung aus. Vererbung basiert auf der Vorstellung, dass Eltern ihren Kindern Eigenschaften mitgeben. Vererbung bindet die Klassen sehr dicht aneinander. Mittels dieser engen Verbindung können wir später sehen, dass Klassen in gewisser Weise austauschbar sind. Ein Programm kann ausdrücken: Gib mir irgendein Obststück, und es bekommt dann vielleicht einen Apfel oder eine Birne.


Galileo Computing - Zum Seitenanfang

6.8.1 Vererbung in Java Zur nächsten ÜberschriftZur vorigen Überschrift

Java ordnet Klassen in hierarchischen Relationen an, in der sie Ist-eine-Art-von-Beziehungen bilden. Eine neu deklarierte Klasse erweitert durch das Schlüsselwort extends eine andere Klasse. Sie wird dann zur Unterklasse (auch Subklasse oder Kindklasse genannt). Die Klasse, von der die Unterklasse erbt, heißt Oberklasse (auch Superklasse oder Elternklasse). Durch den Vererbungsmechanismus werden alle sichtbaren Eigenschaften der Oberklasse auf die Unterklasse übertragen. Eine Oberklasse vererbt also Eigenschaften, und die Unterklasse erbt sie.


Hinweis In Java können nur Untertypen von Klassen deklariert werden. Einschränkungen von primitiven Typen – etwa im Wertebereich oder in der Anzahl der Nachkommastellen – sind nicht möglich. Die Programmiersprache Ada erlaubt das zum Beispiel, und Untertypen sind bei XML Schema üblich, wo etwa xs:short oder xs:unsignedByte ein Untertyp von xs:integer sind.



Galileo Computing - Zum Seitenanfang

6.8.2 Spielobjekte modelliert Zur nächsten ÜberschriftZur vorigen Überschrift

Wir wollen nun eine Klassenhierarchie für Objekte in unserem Spiel aufbauen. Bisher haben wir Spieler, Schlüssel und Räume, aber andere Objekte kommen später noch hinzu. Eine Gemeinsamkeit der Objekte ist, dass sie Spielobjekte sind und alle im Spiel einen Namen haben: Der Raum heißt etwa »Knochenbrecherburg«, der Spieler »James Blond« und der Schlüssel »Magic Wand«.

All diese Objekte sind Spielobjekte und durch ihre Eigenschaft, dass sie alle denselben Namen haben, miteinander verwandt. Die Ist-eine-Art-von-Hierarchie muss aber nicht auf einer Ebene aufhören. Wir könnten uns einen privilegierten Spieler als Spezialisierung vom Spieler vorstellen, der zusätzlich Dinge darf, die ein normaler Spieler nicht darf. Damit ist ein normaler Spieler eine Art von Spielobjekt, ein privilegierter Spieler ist eine Art von Spieler, und transitiv gilt weiterhin, dass ein privilegierter Spieler eine Art von Spielobjekt ist.

Schreiben wir die Hierarchie für zwei Spielobjekte auf: für den Spieler und den Raum. Der Raum hat zusätzlich eine Größe. Die Basisklasse (Oberklasse) soll GameObject sein.

Listing 6.53 com/tutego/insel/game/vd/GameObject.java, GameObject

public class GameObject 
{ 
  public String name; 
}

Der Player soll einfach nur das GameObject erweitern und nichts hinzufügen.

Listing 6.54 com/tutego/insel/game/vd/Player.java, Player

public class Player extends GameObject 
{ 
}

Syntaktisch wird die Vererbung durch das Schlüsselwort extends beschrieben. Die Deklaration der Klasse Player trägt den Anhang extends GameObject und erbt somit alle sichtbaren Eigenschaften der Oberklasse, also das Attribut name. Die vererbten Eigenschaften behalten ihre Sichtbarkeit, sodass eine public Eigenschaft weiterhin public bleibt. Private Eigenschaften sind für andere Klassen nicht sichtbar, also auch nicht für die Unterklassen; sie erben somit private Eigenschaften nicht.

Der Raum soll neben dem geerbten Namen noch eine Größe besitzen:

Listing 6.55 com/tutego/insel/game/vd/Room.java, Room

public class Room extends GameObject 
{ 
  public int size; 
}

Die Klasse Room kann die vererbten Eigenschaften nutzen, also etwa auf die Variable name zurückgreifen. Wenn sich in der Oberklasse der Typ der Variablen oder die Implementierung einer Methode ändert, wird auch die Unterklasse diese Änderung zu spüren bekommen. Daher ist die Kopplung mittels Vererbung sehr eng, denn die Unterklassen sind Änderungen der Oberklassen ausgeliefert, da ja Oberklassen nichts von Unterklassen wissen.

Damit ergibt sich das nachfolgende UML-Diagramm. Die Vererbung ist durch einen Pfeil in Richtung der Oberklasse angegeben.

Die Unterklassen Room und Player besitzen alle sichtbaren Eigenschaften der Oberklasse und zusätzlich ihre hinzugefügten.

Listing 6.56 com/tutego/insel/game/vd/Playground.java, Ausschnitt

Room clinic = new Room(); 
clinic.name = "Clinic";                 // Geerbtes Attribut 
clinic.size = 120000;                   // Eigenes Attribut 
 
Player theDoc = new Player(); 
theDoc.name = "Dr. Schuwibscho";        // Geerbtes Attribut

Galileo Computing - Zum Seitenanfang

6.8.3 Implizite Basisklasse java.lang.Object Zur nächsten ÜberschriftZur vorigen Überschrift

Steht keine ausdrückliche extends-Anweisung hinter einem Klassennamen – wie in dem Beispiel GameObject –, erbt die Klasse automatisch von Object, einer impliziten Basisklasse. Steht also keine ausdrückliche Oberklasse, wie bei

class GameObject

so ist das gleichwertig zu

class GameObject extends Object

Alle Klassen haben somit direkt oder indirekt die Klasse java.lang.Object als Basisklasse und erben so eine Reihe von Methoden, wie toString().


Galileo Computing - Zum Seitenanfang

6.8.4 Einfach- und Mehrfachvererbung Zur nächsten ÜberschriftZur vorigen Überschrift

In Java ist auf direktem Weg nur die Einfachvererbung (engl. single inheritance) erlaubt, sodass hinter dem Schlüsselwort extends lediglich eine einzige Klasse steht. Andere objektorientierte Programmiersprachen, wie C++ [Bjarne Stroustrup hat Mehrfachvererbung erst in C++ 2.0 (1985–1987) eingeführt.] , Python, Perl oder Eiffel, erlauben Mehrfachvererbung und können mehrere Klassen zu einer neuen verbinden. Doch warum bietet Java neben anderen Sprachen wie C#, Objective-C, Simula, Ruby oder Delphi keine Mehrfachvererbung auf Klassenebene?

Nehmen wir an, die Klassen O1 und O2 deklarieren beide eine öffentliche Methode f(), und U ist eine Klasse, die von O1 und O2 erbt. Steht in U ein Methodenaufruf f(), ist nicht klar, welche der beiden Methoden gemeint ist. In C++ löst der Scope-Operator (::) das Problem, indem der Entwickler immer angibt, aus welcher Oberklasse die Funktion anzusprechen ist.

Dazu gesellt sich das Diamanten-Problem (auch Rauten-Problem genannt). Zwei Klassen K1 und K2 erben von einer Oberklasse O eine Eigenschaft x. Eine Unterklasse U erbt von den Klassen K1 und K2. Lässt sich in U auf die Eigenschaft x zugreifen? Eigentlich existiert die Eigenschaft ja nur einmal und dürfte kein Grund zur Sorge sein. Dennoch stellt dieses Szenario ein Problem dar, weil der Compiler »vergessen« hat, dass sich x in den Unterklassen K1 und K2 nicht verändert hat; mit der Einfachvererbung kommt es erst gar nicht zu diesem Dilemma.

Immer wieder wird diskutiert, ob das Fehlen der Mehrfachvererbung Java einschränkt. Die Antwort ist zu verneinen. Java erlaubt zwar keine multiplen Oberklassen, aber immer noch, mehrere Schnittstellen (Interfaces) zu implementieren und so unterschiedliche Typen anzunehmen.


Galileo Computing - Zum Seitenanfang

6.8.5 Sichtbarkeit protected Zur nächsten ÜberschriftZur vorigen Überschrift

Eine Unterklasse erbt alle sichtbaren Eigenschaften. Dazu gehören alle public-Elemente und, falls sich Unterklasse und Oberklasse im gleichen Paket befinden, auch die paketsichtbaren Eigenschaften. Die Vererbung kann durch private eingeschränkt werden, dann sieht keine andere Klasse die Eigenschaften, weder fremde noch Unterklassen.

Neben diesen drei Sichtbarkeiten kommt eine vierte hinzu: protected. Diese Sichtbarkeit umfasst (seltsamerweise) zwei Eigenschaften:

  • protected-Eigenschaften werden an alle Unterklassen vererbt.
  • Klassen, die sich im gleichen Paket befinden, können alle protected-Eigenschaften sehen, denn protected ist eine Erweiterung der Paketsichtbarkeit.

Sind also weitere Klassen im gleichen Paket und Eigenschaften protected, ist die Sichtbarkeit für sie public. Für andere Nicht-Unterklassen in anderen Paketen sind die protected-Eigenschaften private. Damit lassen sich die Sichtbarkeiten so ordnen:

public > protected > paketsichtbar > private


Galileo Computing - Zum Seitenanfang

6.8.6 Konstruktoren in der Vererbung und super topZur vorigen Überschrift

Obwohl Konstruktoren Ähnlichkeit mit Methoden haben, etwa in der Eigenschaft, dass sie überladen werden oder Ausnahmen erzeugen können, werden sie im Gegensatz zu Methoden nicht vererbt. Das heißt, eine Unterklasse muss ganz neue Konstruktoren angeben, denn mit den Konstruktoren der Oberklasse kann ein Objekt der Unterklasse nicht erzeugt werden. Ob das nun reine Objektorientierung ist – darüber lässt sich streiten; in der Skriptsprache Python etwa werden auch Konstruktoren vererbt. In Java gehören Konstruktoren eigentlich zum statischen Teil einer Klasse. Die Klasse selbst weiß, wie neue Objekte konstruiert werden. Sähen wir Konstruktoren eher als Initialisierungsmethoden an, läge es natürlich näher, sie wie Objektmethoden zu behandeln. Dagegen spricht jedoch, dass eine Unterklasse mehr Eigenschaften hat und der Konstruktor der Oberklasse dann nur einen Teil initialisieren würde.

In Java sammelt eine Unterklasse zwar automatisch alle sichtbaren Eigenschaften der Oberklasse, aber die Initialisierung der einzelnen Eigenschaften pro Hierarchie ist immer noch Aufgabe der jeweiligen Konstruktoren in der Hierarchie. Um diese Initialisierung sicherzustellen, ruft Java im Konstruktor einer jeden Klasse (ausgenommen java.lang.Object) automatisch den Standard-Konstruktor der Oberklasse auf, damit die Oberklasse »ihre« Attribute initialisieren kann. Es ist dabei egal, ob der Konstruktor in der Unterklasse parametrisiert ist oder nicht; jeder Konstruktor der Unterklasse muss einen der Oberklasse aufrufen.

Ein Beispiel mit Konstruktorweiterleitung

Sehen wir uns noch einmal die Konstruktorverkettung an:

class GameObject 
{ 
} 
 
class Player extends GameObject 
{ 
}

Da wir keine expliziten Konstruktoren haben, fügt der Compiler diese ein, und da GameObject von java.lang.Object erbt, sieht die Laufzeitumgebung die Klassen so:

class GameObject 
{ 
  GameObject() { } 
} 
 
class Player extends GameObject 
{ 
  Player() { } 
}

Das Schlüsselwort super

Dass automatisch jeder Konstruktor einer Klasse den Standard-Konstruktor der Oberklasse aufruft, lässt sich auch explizit formulieren – das nötige Schlüsselwort ist super(). Da der Compiler automatisch super() als erste Anweisung in den Konstruktor einfügt, müssen wir das nicht manuell hinschreiben und sollten es uns auch sparen – unsere Fingerkraft ist wichtig für andere Dinge! Ob wir also nun von Hand super() in den Konstruktor platzieren oder es vom Compiler einsetzen lassen, für die Laufzeitumgebung ist die vorangehende Schreibweise oder die folgende völlig gleich.

class GameObject extends Object 
{ 
  GameObject() 
  { 
    super();         // Ruft Standard-Konstruktor von Object auf 
  } 
} 
 
class Player extends GameObject 
{ 
  Player() 
  { 
    super();         // Ruft Standard-Konstruktor von GameObject auf 
  } 
}

Hinweis super() muss immer die erste Anweisung im Konstruktor sein. Beim Aufbau neuer Objekte läuft die Laufzeitumgebung daher als Erstes die Hierarchie nach java.lang.Object ab und beginnt dort von oben nach unten mit der Initialisierung. Kommt der eigene Konstruktor an die Reihe, konnten die Konstruktoren der Oberklasse ihre Werte schon initialisieren.


Super auch bei parametrisierten Konstruktoren

Nicht nur die Standard-Konstruktoren rufen mit super() den Standard-Konstruktor der Oberklasse auf, sondern auch immer die parametrisierten Konstruktoren. Nehmen wir eine Klasse für Außerirdische mit einem parametrisierten Konstruktor für den Namen des Planeten an:

Listing 6.57 com/tutego/insel/game/vd/Alien.java, Alien

public class Alien extends GameObject 
{ 
  public String planet; 
 
  public Alien( String planet ) 
  { 
    this.planet = planet; 
  } 
}

Auch wenn es hier keinen Standard-Konstruktor gibt, sondern nur einen parametrisierten, ruft auch dieser automatisch den Standard-Konstruktor der Basisklasse GameObject auf. Explizit ausgeschrieben heiß das:

public Alien( String planet ) 
{ 
  super();                  // Ruft automatisch Standard-Konstruktor  
                            // von GameObject auf 
  this.planet = planet; 
}

Natürlich muss super() wieder als Erstes stehen.

super() mit Argumenten füllen

Mitunter ist es nötig, aus der Unterklasse nicht nur den Standard-Konstruktor anzusteuern, sondern einen anderen (parametrisierten) Konstruktor der Oberklasse anzusprechen. Dazu gibt es das super() mit Argumenten.

Der Aufruf von super() kann parametrisiert erfolgen, sodass nicht der Standard-Konstruktor, sondern ein parametrisierter Konstruktor aufgerufen wird. Gründe dafür könnten sein:

  • Ein parametrisierter Konstruktor der Unterklasse leitet die Argumente an die Oberklasse weiter; es soll nicht der Standard-Konstruktor aufgerufen werden, da der Oberklassen-Konstruktor das Attribut annehmen und verarbeiten soll.
  • Wenn wir keinen Standard-Konstruktor in der Oberklasse vorfinden, müssen wir in der Unterklasse mittels super(Argument ...) einen speziellen, parametrisierten Konstruktor aufrufen.

Gehen wir Schritt für Schritt eine Vererbungshierarchie durch, um zu verstehen, dass ein super() mit Parameter nötig ist.

Beginnen wir mit einer Klasse Alien, die in einem parametrisierten Konstruktor den Planetennamen erwartet:

Listing 6.58 Alien.java

public class Alien 
{ 
  public String planet; 
  public Alien( String planet ) { this.planet = planet; } 
}

Erweitert eine Klasse Grob für eine besondere Art von Außerirdischen die Klasse Alien, kommt es zu einem Compilerfehler.

public class Grob extends Alien { }

Der Fehler vom Eclipse-Compliler ist: »Implicit super constructor Alien() is undefined. Must explicitly invoke another constructor.«

Der Grund ist simpel: Grob enthält einen Compiler-generierten Standard-Konstruktor, der mit super() nach einem Standard-Konstruktor in Alien sucht – den gibt es aber nicht. Wir müssen daher entweder einen Standard-Konstruktor in der Oberklasse anlegen – was bei nicht modifizierbaren Klassen natürlich nicht geht – oder das super() in Grob so einsetzen, dass es mit einem Argument den parametrisierten Konstruktor der Oberklasse aufruft. Das kann so aussehen:

Listing 6.59 Grob.java

public class Grob extends Alien 
{ 
  public Grob() 
  { 
    super( "Locutus" );    // Alle Grobs leben auf Locutus 
  } 
}

Es spielt dabei keine Rolle, ob Grob einen Standard-Konstruktor oder einen parametrisierten Konstruktor besitzt: In beiden Fällen müssen wir mit super() einen Wert an den Konstruktor der Basisklasse übergeben. Oftmals leiten Unterklassen einfach nur den Konstruktorwert an die Oberklasse weiter:

public class Grob extends Alien 
{ 
  public Grob( String planet ) 
  { 
    super( planet ); 
  } 
}

Zusammenfassung: Konstruktoren und Methoden

Methoden und Konstruktoren haben einige Gemeinsamkeiten in der Signatur, weisen aber auch einige wichtige Unterschiede auf, wie den Rückgabewert oder den Gebrauch von this und super. Die folgende Tabelle fasst die Unterschiede und Gemeinsamkeiten noch einmal kompakt zusammen: [Schon seltsam, dass synchronized nicht erlaubt ist, aber ein Konstruktor ist implizit synchronized. Auch ein indirekter Weg über die Class-Methode newInstance() bringt uns nicht zum Ziel, sondern wir handeln uns nur eine InstantiationException ein.]


Tabelle 6.2 Gegenüberstellung von Konstruktoren und Methoden

Benutzung Konstruktoren Methoden

Modifizierer

Sichtbarkeit public, protected, paketsichtbar und private. Können nicht abstract, final, native, static oder synchronized sein.

Sichtbarkeit public, protected, paketsichtbar und private. Können abstract, final, native, static oder synchronized sein.

Rückgabewert

kein Rückgabewert, auch nicht void

Rückgabetyp oder void

Bezeichnername

Gleicher Name wie die Klasse. Beginnt mit einem Großbuchstaben.

Beliebig. Beginnt mit einem Kleinbuchstaben.

this

this() bezieht sich auf einen anderen Konstruktor der gleichen Klasse. Wird this() benutzt, muss this() in der ersten Zeile stehen.

this ist eine Referenz in Objektmethoden, die sich auf das aktuelle Exemplar bezieht.

super

Ruft einen Konstruktor der Oberklasse auf. Wird super() benutzt, muss super() in der ersten Zeile stehen.

super ist eine Referenz mit dem Namensraum der Oberklasse. Damit lassen sich überschriebene Methoden aufrufen.

Vererbung

Konstruktoren werden nicht vererbt.

Sichtbare Methoden werden vererbt.




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

 Tipp
Zum Katalog: Coding for Fun





 Coding for Fun


 Buchempfehlungen
Zum Katalog: Objektorientierte Programmierung





 Objektorientierte
 Programmierung


Zum Katalog: Einstieg in Eclipse 3.4






 Einstieg in
 Eclipse 3.4


Zum Katalog: Java 6 lernen mit Eclipse






 Java 6 lernen
 mit Eclipse


Zum Katalog: NetBeans Platform 6






 NetBeans
 Platform 6


Zum Katalog: Java und XML






 Java und XML


Zum Katalog: Visual C# 2008






 Visual C# 2008


Zum Katalog: IT-Handbuch für Fachinformatiker






 IT-Handbuch für
 Fachinformatiker


Zum Katalog: C++ von A bis Z






 C++ von A bis Z


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




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