Rheinwerk Computing < openbook >


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


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

Pfeil 7 Objektorientierte Beziehungsfragen
Pfeil 7.1 Assoziationen zwischen Objekten
Pfeil 7.1.1 Unidirektionale 1:1-Beziehung
Pfeil 7.1.2 Zwei Freunde müsst ihr werden – bidirektionale 1:1-Beziehungen
Pfeil 7.1.3 Unidirektionale 1:n-Beziehung
Pfeil 7.2 Vererbung
Pfeil 7.2.1 Vererbung in Java
Pfeil 7.2.2 Ereignisse modellieren
Pfeil 7.2.3 Die implizite Basisklasse java.lang.Object
Pfeil 7.2.4 Einfach- und Mehrfachvererbung *
Pfeil 7.2.5 Sehen Kinder alles? Die Sichtbarkeit protected
Pfeil 7.2.6 Konstruktoren in der Vererbung und super(…)
Pfeil 7.3 Typen in Hierarchien
Pfeil 7.3.1 Automatische und explizite Typumwandlung
Pfeil 7.3.2 Das Substitutionsprinzip
Pfeil 7.3.3 Typen mit dem instanceof-Operator testen
Pfeil 7.3.4 Pattern-Matching bei instanceof
Pfeil 7.4 Methoden überschreiben
Pfeil 7.4.1 Methoden in Unterklassen mit neuem Verhalten ausstatten
Pfeil 7.4.2 Mit super an die Eltern
Pfeil 7.5 Drum prüfe, wer sich dynamisch bindet
Pfeil 7.5.1 Gebunden an toString()
Pfeil 7.5.2 Implementierung von System.out.println(Object)
Pfeil 7.6 Finale Klassen und finale Methoden
Pfeil 7.6.1 Finale Klassen
Pfeil 7.6.2 Nicht überschreibbare (finale) Methoden
Pfeil 7.7 Abstrakte Klassen und abstrakte Methoden
Pfeil 7.7.1 Abstrakte Klassen
Pfeil 7.7.2 Abstrakte Methoden
Pfeil 7.8 Weiteres zum Überschreiben und dynamischen Binden
Pfeil 7.8.1 Nicht dynamisch gebunden bei privaten, statischen und finalen Methoden
Pfeil 7.8.2 Kovariante Rückgabetypen
Pfeil 7.8.3 Array-Typen und Kovarianz *
Pfeil 7.8.4 Dynamisch gebunden auch bei Konstruktoraufrufen *
Pfeil 7.8.5 Keine dynamische Bindung bei überdeckten Objektvariablen *
Pfeil 7.9 Zum Weiterlesen und Programmieraufgabe
 

Zum Seitenanfang

7.6    Finale Klassen und finale Methoden Zur vorigen ÜberschriftZur nächsten Überschrift

Bisher haben wir den Modifizierer final immer nur im Zusammenhang mit Variablen kennengelernt. Dann bedeutet er, dass die Variable nur einmal zur Initialisierung beschrieben werden darf. final taucht aber auch als Modifizierer bei Klassen und Methoden auf.

 

Zum Seitenanfang

7.6.1    Finale Klassen Zur vorigen ÜberschriftZur nächsten Überschrift

Soll eine Klasse keine Unterklassen bilden, werden Klassen mit dem Modifizierer final versehen. Dadurch lässt sich vermeiden, dass Unterklassen Eigenschaften nachträglich verändern. Ein Versuch, von einer finalen Klasse zu erben, führt zu einem Compilerfehler. Dies schränkt zwar die objektorientierte Wiederverwendung ein, wird aber aufgrund von Sicherheitsaspekten in Kauf genommen. Eine Passwortüberprüfung soll zum Beispiel nicht einfach überschrieben werden können.

In der Java-Bibliothek gibt es eine Reihe finaler Klassen, von denen wir einige bereits kennen:

  • String, StringBuilder

  • Integer, Double … (Wrapper-Klassen)

  • Math

  • System, Locale

  • Color

[+]  Tipp

Eine protected-Eigenschaft in einer als final deklarierten Klasse ergibt wenig Sinn, da ja keine Unterklasse möglich ist, die diese Methode oder Variable nutzen kann. Daher sollte die Eigenschaft dann paketsichtbar sein (protected enthält ja »paketsichtbar«) oder gleich private oder public.

 

Zum Seitenanfang

7.6.2    Nicht überschreibbare (finale) Methoden Zur vorigen ÜberschriftZur nächsten Überschrift

Nehmen wir an, ein Ereignis hat eine format()-Methode, die eine String-Repräsentation nach der ISO-8601-Norm zurückgibt und das auch dokumentiert:

Listing 7.37     src/main/java/com/tutego/insel/game/c/vo/Event.java, Event

public class Event {

public int duration;



/**

* @return a string representation of this event duration using ISO-8601.

*/

public String format() {

return Duration.ofMinutes( duration ).toString();

}

}

So sieht der String zum Beispiel aus:

Event flight = new Event();

flight.duration = 6 /* h */ * 60 + 12 /* min */;

System.out.println( flight.format() ); // PT6H12M

Eine Unterklasse SportsEvent findet nun diese Notation zu schwer zu lesen und stellt sie anders dar:

public class SportsEvent extends Event {

@Override public String format() {

return duration + " minutes";

}

}

Das Ergebnis ist wie zu erwarten:

Event schalkeBvb = new SportsEvent();

schalkeBvb.duration = 90;

System.out.println( schalkeBvb.format() ); // 90 minutes

Das Problem hierbei ist ein Verstoß gegen das liskovsche Substitutionsprinzip. Eine Unterklasse darf den »Vertrag« nicht brechen, und wenn der Basistyp ein gewisses Format verspricht, dann müssen sich Unterklassen auch daran halten.

Ein Lösungsansatz besteht darin, den Unterklassen das Überschreiben einer Methode zu verbieten. Das wird durch den Modifizierer final an der Methodendeklaration erreicht:

final public String format() {

return Duration.ofMinutes( duration ).toString();

}

Nehmen wir in Event bei der Methode format() den Modifizierer final hinzu, dann meldet der Compiler bei der Unterklasse SportEvent einen Fehler:

'format()' cannot override 'format()' in [...].Event'; overridden method is final

Da Methodenaufrufe immer dynamisch gebunden werden, kann ein Aufrufer nicht mehr unbeabsichtigt in der Unterklasse landen – finale Methoden verhindern das.

[»]  Hinweis

Auch private Methoden können final sein, aber private Methoden lassen sich ohnehin nicht überschreiben (sie werden überdeckt), sodass final überflüssig ist.

 


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: Algorithmen in Java

Algorithmen in Java




Zum Rheinwerk-Shop: Spring Boot 3 und Spring Framework 6

Spring Boot 3 und Spring Framework 6




Zum Rheinwerk-Shop: Java SE 9 Standard-Bibliothek

Java SE 9 Standard-Bibliothek




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

InfoInfo



 

 


Copyright © Rheinwerk Verlag GmbH 2024

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