Rheinwerk Computing < openbook >


 
Inhaltsverzeichnis
Materialien
Vorwort
1 Java ist auch eine Sprache
2 Imperative Sprachkonzepte
3 Klassen und Objekte
4 Arrays und ihre Anwendungen
5 Der Umgang mit Zeichenketten
6 Eigene Klassen schreiben
7 Objektorientierte Beziehungsfragen
8 Ausnahmen müssen sein
9 Geschachtelte Typen
10 Besondere Typen der Java SE
11 Generics<T>
12 Lambda-Ausdrücke und funktionale Programmierung
13 Architektur, Design und angewandte Objektorientierung
14 Java Platform Module System
15 Die Klassenbibliothek
16 Einführung in die nebenläufige Programmierung
17 Einführung in Datenstrukturen und Algorithmen
18 Einführung in grafische Oberflächen
19 Einführung in Dateien und Datenströme
20 Einführung ins Datenbankmanagement mit JDBC
21 Bits und Bytes, Mathematisches und Geld
22 Testen mit JUnit
23 Die Werkzeuge des JDK
A Java SE-Module und Paketübersicht
Stichwortverzeichnis


Download:

- Listings, ca. 2,7 MB


Buch bestellen
Ihre Meinung?



Spacer
<< zurück
Java ist auch eine Insel von Christian Ullenboom

Einführung, Ausbildung, Praxis
Buch: Java ist auch eine Insel


Java ist auch eine Insel

Pfeil7 Objektorientierte Beziehungsfragen
Pfeil7.1 Assoziationen zwischen Objekten
Pfeil7.1.1 Unidirektionale 1:1-Beziehung
Pfeil7.1.2 Zwei Freunde müsst ihr werden – bidirektionale 1:1-Beziehungen
Pfeil7.1.3 Unidirektionale 1:n-Beziehung
Pfeil7.2 Vererbung
Pfeil7.2.1 Vererbung in Java
Pfeil7.2.2 Spielobjekte modellieren
Pfeil7.2.3 Die implizite Basisklasse java.lang.Object
Pfeil7.2.4 Einfach- und Mehrfachvererbung *
Pfeil7.2.5 Sehen Kinder alles? Die Sichtbarkeit protected
Pfeil7.2.6 Konstruktoren in der Vererbung und super(…)
Pfeil7.3 Typen in Hierarchien
Pfeil7.3.1 Automatische und explizite Typumwandlung
Pfeil7.3.2 Das Substitutionsprinzip
Pfeil7.3.3 Typen mit dem instanceof-Operator testen
Pfeil7.4 Methoden überschreiben
Pfeil7.4.1 Methoden in Unterklassen mit neuem Verhalten ausstatten
Pfeil7.4.2 Mit super an die Eltern
Pfeil7.4.3 Finale Klassen und finale Methoden
Pfeil7.4.4 Kovariante Rückgabetypen
Pfeil7.4.5 Array-Typen und Kovarianz *
Pfeil7.5 Drum prüfe, wer sich dynamisch bindet
Pfeil7.5.1 Gebunden an toString()
Pfeil7.5.2 Implementierung von System.out.println(Object)
Pfeil7.5.3 Nicht dynamisch gebunden bei privaten, statischen und finalen Methoden
Pfeil7.5.4 Dynamisch gebunden auch bei Konstruktoraufrufen *
Pfeil7.5.5 Eine letzte Spielerei mit Javas dynamischer Bindung und überdeckten Attributen *
Pfeil7.6 Abstrakte Klassen und abstrakte Methoden
Pfeil7.6.1 Abstrakte Klassen
Pfeil7.6.2 Abstrakte Methoden
Pfeil7.7 Schnittstellen
Pfeil7.7.1 Schnittstellen sind neue Typen
Pfeil7.7.2 Schnittstellen deklarieren
Pfeil7.7.3 Abstrakte Methoden in Schnittstellen
Pfeil7.7.4 Implementieren von Schnittstellen
Pfeil7.7.5 Ein Polymorphie-Beispiel mit Schnittstellen
Pfeil7.7.6 Die Mehrfachvererbung bei Schnittstellen
Pfeil7.7.7 Keine Kollisionsgefahr bei Mehrfachvererbung *
Pfeil7.7.8 Erweitern von Interfaces – Subinterfaces
Pfeil7.7.9 Konstantendeklarationen bei Schnittstellen
Pfeil7.7.10 Nachträgliches Implementieren von Schnittstellen *
Pfeil7.7.11 Statische ausprogrammierte Methoden in Schnittstellen
Pfeil7.7.12 Erweitern und Ändern von Schnittstellen
Pfeil7.7.13 Default-Methoden
Pfeil7.7.14 Erweiterte Schnittstellen deklarieren und nutzen
Pfeil7.7.15 Öffentliche und private Schnittstellenmethoden
Pfeil7.7.16 Erweiterte Schnittstellen, Mehrfachvererbung und Mehrdeutigkeiten *
Pfeil7.7.17 Bausteine bilden mit Default-Methoden *
Pfeil7.7.18 Initialisierung von Schnittstellenkonstanten *
Pfeil7.7.19 Markierungsschnittstellen *
Pfeil7.7.20 (Abstrakte) Klassen und Schnittstellen im Vergleich
Pfeil7.8 SOLIDe Modellierung
Pfeil7.8.1 DRY, KISS und YAGNI
Pfeil7.8.2 SOLID
Pfeil7.8.3 Sei nicht STUPID
Pfeil7.9 Zum Weiterlesen
 

Zum Seitenanfang

7.2    Vererbung Zur vorigen ÜberschriftZur nächsten Überschrift

Schon von Kindheit an lernen wir, Objekte in Beziehung zu setzen. Assoziationen bilden dabei die Hat-Beziehung zwischen Objekten ab: Ein Teddy hat (direkt 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 bzw. die Generalisierung[ 157 ](»All generalizations are false, including this one.« (Mark Twain) )/Spezialisierung (siehe Abbildung 7.6). Apfel und Birne sind Obstsorten, Lotad, Seedot und Wingull sind verschiedene Pokémon, und »Berg« ist der Sammelbegriff und die Kategorie für K2 und Mount Everest.[ 158 ](So etwas gibt es auch in der Linguistik; dort heißt der Oberbegriff eines Begriffs Hyperonym und der Unterbegriff eines Begriffs Hyponym. )

Beispiele zur VererbungVererbung und Assoziation

Abbildung 7.6    Beispiele zur 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.[ 159 ](Semantische Netzwerke sind in der kognitiven Psychologie ein Erklärungsmodell 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 eine intuitive Vorstellung, und jeder Berg hat eine Höhe und einen Namen sowie eine Reihe von Besteigern.

Programmiersprachen drücken Gruppierung und Hierarchiebildung über die Vererbung 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.

 

Zum Seitenanfang

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

Java ordnet Typen in hierarchischen Relationen an, in denen 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, Kindklasse oder Erweiterungsklasse genannt). Die Klasse, von der die Unterklasse erbt, heißt Oberklasse (auch Superklasse oder Elternklasse). Auch die Begriffe Vorfahre und Nachkomme werden von manchen Autoren verwendet.

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 beim XML-Schema üblich, wo etwa xs:short oder xs:unsignedByte Untertypen von xs:integer sind.

 

Zum Seitenanfang

7.2.2    Spielobjekte modellieren Zur vorigen ÜberschriftZur nächsten Ü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 ein Attribut für einen Namen haben, sind sie 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 des Spielers vorstellen. Der privilegierte Spieler darf zusätzlich Dinge tun, die ein normaler Spieler nicht tun darf. Damit ist ein normaler Spieler eine Art von Spielobjekt, ein privilegierter Spieler ist eine Art von Spieler, und transitiv gilt, dass ein privilegierter Spieler eine Art von Spielobjekt ist.

Schreiben wir die Hierarchie für zwei Spielobjekte auf: für den Spieler und für den Raum. Der Raum hat zusätzlich eine Größe. Die Basisklasse (Oberklasse) soll GameObject sein[ 160 ](In der Spieleprogrammierung ist die Modellierung anders und es wird oft das Entity-Component-Muster (https://en.wikipedia.org/wiki/Entity_component_system) eingesetzt. Nach diesem Ansatz würde die Oberklasse eher »Entity« heißen und statt Unterklassen würde Assoziation verwendet werden. Der Name »Entity« ist in der Java-Enterprise-Welt für ein persistentes Objekt belegt. ):

Listing 7.11    src/main/java/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 7.12    src/main/java/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. Damit erbt Player alle sichtbaren Eigenschaften der Oberklasse, also das Attribut name. Die vererbten Eigenschaften behalten ihre Sichtbarkeit, sodass eine Eigenschaft public 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 7.13    src/main/java/com/tutego/insel/game/vd/Room.java, Room

public class Room extends GameObject {

public int size;

}

Die Klasse Room kann die geerbten 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 UML-Diagramm aus Abbildung 7.7. Die Vererbung ist durch einen Pfeil in Richtung der Oberklasse angegeben.

»Room« und »Player« sind zwei Unterklassen von »GameObject«.

Abbildung 7.7    »Room« und »Player« sind zwei Unterklassen von »GameObject«.

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

Listing 7.14    src/main/java/com/tutego/insel/game/vd/Playground.java, Ausschnitt

Room clinic = new Room();

clinic.name = "Clinic"; // Zugriff auf geerbtes Attribut

clinic.size = 120000; // Zugriff auf eigenes Attribut



Player theDoc = new Player();

theDoc.name = "Dr. Schuwibscho"; // Zugriff auf geerbtes Attribut

Der Nutzer weiß im Grunde nicht, warum ein Typ etwas »hat« und aus welcher (Basis-)Klasse die Eigenschaften kommen.

 

Zum Seitenanfang

7.2.3    Die implizite Basisklasse java.lang.Object Zur vorigen ÜberschriftZur nächsten Überschrift

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

class GameObject

so ist das gleichwertig mit:

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(). Daher tauchen in der Tastaturvervollständigung einer IDE auch immer Methoden auf, die nicht von den eigenen Klassen stammen (siehe Abbildung 7.8).

Methoden aus der absoluten Oberklasse »java.lang.Object«

Abbildung 7.8    Methoden aus der absoluten Oberklasse »java.lang.Object«

 

Zum Seitenanfang

7.2.4    Einfach- und Mehrfachvererbung * Zur vorigen ÜberschriftZur nächsten Ü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++[ 161 ](Bjarne Stroustrup führte Mehrfachvererbung erst in C++ 2.0 (1985–1987) ein. ), 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 es dürfte keinen Grund zur Sorge geben. 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. Nein, das tut es nicht wirklich. Java erlaubt zwar keine multiplen Oberklassen, es erlaubt aber immer noch, mehrere Schnittstellen (Interfaces) zu implementieren und so unterschiedliche Typen anzunehmen. Mit Schnittstellen beschäftigen wir uns in Abschnitt 7.7.

 

Zum Seitenanfang

7.2.5    Sehen Kinder alles? Die Sichtbarkeit protected Zur vorigen ÜberschriftZur nächsten Überschrift

Eine Unterklasse erbt alle sichtbaren Eigenschaften. Wir kennen schon public, paketsichtbar private. Daraus folgt:

  • Sind in der Oberklasse die Eigenschaften public, so sehen auch die Unterklassen die Eigenschaften. Überhaupt sieht sie jeder.

  • Hat die Oberklasse paketsichtbare Eigenschaften, sieht die Unterklasse die Eigenschaften nur dann, wenn die Klassen sich im gleichen Paket befinden. Paketsichtbare Eigenschaften bleiben also auch für Unterklassen privat, wenn sich die Klassen in einem anderen Paket befinden.

  • Die Vererbung kann durch private eingeschränkt werden. Dann sieht keine andere Klasse die Eigenschaften: weder fremde Klassen noch Unterklassen.

Bei öffentlichen, paketsichtbaren und privaten Eigenschaften haben Unterklassen also keine Sonderstellung; sie sehen nicht mehr.

[»]  Sprachvergleich

Die Programmiersprache Eiffel hat ein interessantes Feature: Steht an einer neuen Klasse inherit {NONE} Oberklasse, so erbt die Klasse von der genannten Oberklasse, aber die Eigenschaften sind in der neuen Klasse privat und stehen weiteren Unterklassen dieser neuen Klasse nicht zur Verfügung.

Das Schlüsselwort protected

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

[+]  Designtipp

Ist in einer Klasse eine Eigenschaft protected, so ist sie in allen Unterklassen sichtbar, egal in welchem Paket sich die Unterklasse befindet. Wenn etwa A eine protected-Variable hat und B von A erbt und C von B, dann sieht C ebenfalls die protected-Variable. Das ist in der Regel ein Problem für Objektvariablen, weil schnell ein Implementierungsdetail nach außen dringt und der Code fragil wird. Folglich sollte auf protected-Variablen verzichtet werden.

 

Zum Seitenanfang

7.2.6    Konstruktoren in der Vererbung und super(…) Zur vorigen ÜberschriftZur nächsten Ü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. Würden wir Konstruktoren eher als Initialisierungsmethoden ansehen, 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 parameterlosen 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 Konstruktor 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() { }

}

Deutschland sucht den super(…)-Aufruf

Dass automatisch jeder Konstruktor einer Klasse den parameterlosen Konstruktor der Oberklasse aufruft, lässt sich auch explizit formulieren – das nötige Schlüsselwort ist super und formt den Aufruf 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 für andere Dinge wichtig! Ob wir also nun von Hand super(…) im Konstruktor platzieren oder es vom Compiler einsetzen lassen, für die Laufzeitumgebung sind die vorangehende Schreibweise und die folgende völlig gleich:

class GameObject extends Object {

GameObject() {

super(); // Ruft parameterlosen Konstruktor von Object auf

}

}



class Player extends GameObject {

Player() {

super(); // Ruft parameterlosen Konstruktor von GameObject auf

}

}
[»]  Hinweis

super(…) muss immer die erste Anweisung im Konstruktor sein. Beim Aufbau neuer Objekte läuft die Laufzeitumgebung im Konstruktor daher als Erstes die Hierarchie nach java. lang.Object ab und beginnt dort von oben nach unten mit der Initialisierung. Kommt die JVM nach der Initialisierung der Oberklasse durch den Aufruf von super() zurück zum eigenen Konstruktor, haben alle Konstruktoren der Oberklassen ihre Zustände schon initialisiert, und wir können später im eigenen Konstruktor von vollständig initialisierten Variablen aller Basistypen ausgehen.

super(…) auch bei parametrisierten Konstruktoren

Alle Konstruktoren (also die parameterlosen und parametrisierten) rufen mit super(…) standardmäßig den parameterlosen Konstruktor der Oberklasse auf. Nehmen wir eine Klasse für Außerirdische mit einem parametrisierten Konstruktor für den Namen des Planeten an:

Listing 7.15    src/main/java/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 parameterlosen Konstruktor gibt, sondern nur einen parametrisierten, ruft auch dieser automatisch den parameterlosen Konstruktor der Basisklasse GameObject auf. Explizit ausgeschrieben heißt das:

public Alien( String planet ) {

super(); // Ruft automatisch den parameterlosen 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 parameterlosen 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 parameterlose 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 parameterlose Konstruktor aufgerufen werden, da der Oberklassen-Konstruktor das Attribut annehmen und verarbeiten soll.

  • Wenn wir keinen parameterlosen 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 7.16    src/main/java/com/tutego/insel/oop/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 { }   // inline image Compilerfehler

Die Fehlermeldung des Eclipse-Compilers lautet: »Implicit super constructor Alien() is undefined. Must explicitly invoke another constructor.«

Der Grund ist simpel: Grob enthält einen vom Compiler generierten Standard-Konstruktor, der mit super(…) nach einem parameterlosen Konstruktor in Alien sucht – den gibt es aber nicht. Wir müssen daher entweder einen parameterlosen 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 7.17    src/main/java/com/tutego/insel/oop/Grob.java

public class Grob extends Alien {

public Grob() {

super( "Locutus" ); // Alle Grobs leben auf Locutus

}

}

Es spielt dabei keine Rolle, ob Grob einen parameterlosen 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 das Konstruktorargument an die Oberklasse weiter:

public class Grob extends Alien {

public Grob( String planet ) {

super( planet );

}

}

Der this(…)-und-super(…)-Konflikt *

this(…) und super(…) haben eine Gemeinsamkeit: Beide wollen die erste Anweisung eines Konstruktors sein. Es kommt vor, dass es mit super(…) einen parametrisierten Aufruf des Konstruktors der Basisklasse gibt, aber gleichzeitig ein this(…) mit Parametern, um in einem zentralen Konstruktor alle Initialisierungen vornehmen zu können. Beides geht aber leider nicht. Die Lösung besteht darin, auf das this(…) zu verzichten und den gemeinsamen Programmcode in eine private Methode zu setzen. Das kann so aussehen:

Listing 7.18    src/main/java/com/tutego/insel/oop/ColoredLabel.java

import java.awt.Color;

import javax.swing.JLabel;



public class ColoredLabel extends JLabel {



public ColoredLabel() {

initialize( Color.BLACK );

}



public ColoredLabel( String label ) {

super( label );

initialize( Color.BLACK );

}



public ColoredLabel( String label, Color color ) {

super( label );

initialize( color );

}



private void initialize( Color color ) {

setForeground( color );

}

}

Die farbige Beschriftung ColoredLabel ist ein spezielles JLabel. Es kann auf drei Arten initialisiert werden, wobei bei allen Herangehensweisen die Aufgabe gleich ist, dass eine Farbe gespeichert werden muss. Das übernimmt die Methode initialize(Color), die alle Konstruktoren aufrufen. Hier wird dann der Code platziert, den alle Konstruktoren ausführen sollen.

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. Tabelle 7.1 fasst die Unterschiede und Gemeinsamkeiten zusammen:[ 162 ](Schon seltsam, dass synchronized nicht erlaubt ist, aber ein Konstruktor implizit synchronized ist. )

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 ist eine Referenz in Objektmethoden und Konstruktoren, die sich auf das aktuelle Exemplar bezieht.

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

super

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

super(…) ruft einen Konstruktor der Oberklasse auf. Wird es benutzt, muss es die erste Anweisung sein.

Vererbung

Konstruktoren werden nicht vererbt.

Sichtbare Methoden werden vererbt.

Tabelle 7.1    Gegenüberstellung von Konstruktoren und Methoden

 


Ihre Meinung?

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de

<< zurück
 Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Java ist auch eine Insel Java ist auch eine Insel

Jetzt Buch bestellen


 Buchempfehlungen
Zum Rheinwerk-Shop: Captain CiaoCiao erobert Java

Captain CiaoCiao erobert Java




Zum Rheinwerk-Shop: Java SE 9 Standard-Bibliothek

Java SE 9 Standard-Bibliothek




Zum Rheinwerk-Shop: Algorithmen in Java

Algorithmen in Java




Zum Rheinwerk-Shop: Objektorientierte Programmierung

Objektorientierte Programmierung




 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und in die Schweiz

InfoInfo



 

 


Copyright © Rheinwerk Verlag GmbH 2021

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.

 

[Rheinwerk Computing]



Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de



Cookie-Einstellungen ändern