Vererbung, Interfaces und Polymorphie in Java

Vererbung erzeugt eine Unterklasse aus einer bestehenden Oberklasse. In class Student extends Person ist jeder Student eine Person. Ein Studentenobjekt enthält seinen Personenzustand und seinen zusätzlichen Studentenzustand zusammen in einem Objekt.

Ergänze die studentenspezifischen Teile

Hier sind eine kleine Oberklasse und eine Unterklasse:

class Person {
    private String name;
    public Person(String name) { this.name = name; }
    public String getName() { return name; }
}

class Student extends Person {
    private int credits;
    public Student(String name) { super(name); }
    public void study() { credits += 5; }
    public int getCredits() { return credits; }
}

Student erbt getName(). Die Klasse ergänzt ein Feld für Leistungspunkte und zwei Methoden. Nach Student s = new Student("Ada Lovelace"); beginnt das Feld für Leistungspunkte bei 0. Zwei Aufrufe von s.study() erhöhen den Wert zuerst auf 5 und dann auf 10. s.getName() gibt weiterhin „Ada Lovelace“ zurück: Die geerbte Methode liest das in Person deklarierte private Feld.

Die Anweisung super(name) übergibt den Namen an den Konstruktor von Person. Konstruktoren werden nicht geerbt, daher deklariert Student einen eigenen Konstruktor. Eine Unterklasse darf Methoden ergänzen und geerbtes Verhalten überschreiben, kann aber eine geerbte öffentliche Methode nicht aus ihrer öffentlichen Schnittstelle entfernen.

Bestimme, auf welche Mitglieder zugegriffen werden kann

Private Mitglieder werden nicht geerbt. Das private Feld name existiert weiterhin in jedem Studentenobjekt, aber Student kann es nicht direkt lesen. Indem Person das Feld privat hält und einen Getter bereitstellt, kontrolliert die Klasse ihre eigenen Daten. Über Paketgrenzen hinweg gilt für den protected-Instanzzugriff eine zusätzliche Einschränkung: Der Code der Unterklasse greift über sich selbst oder eine Referenz ihres eigenen Unterklassentyps auf das Mitglied zu, nicht über eine beliebige Oberklassenreferenz.

Prüfe die Beziehung vor dem Erweitern

Java erlaubt eine direkte Oberklasse pro Klasse. Eine Kette wie GraduateStudent extends Student und Student extends Person ist gültig; extends Student, Teacher ist es nicht. Eine Klasse ohne explizite Oberklasse erweitert Object. Object selbst hat keine Oberklasse.

Verwende den Ist-ein-Test: Kann jedes Unterklassenobjekt überall dort verwendet werden, wo die Oberklasse erwartet wird? Ein Lastwagen ist ein Fahrzeug. Ein Kunde hat eine Adresse, aber ein Kunde ist keine Adresse. Verwende für die zweite Beziehung Komposition:

class Customer {
    private Address address;
}

Hier ist Address eine andere Klasse. Das Feld ermöglicht einem Kunden, eine Adresse zu verwenden, ohne zu behaupten, selbst eine zu sein. Wer eine Klasse nur erweitert, um eine praktische Methode zu übernehmen, erbt auch ihren gesamten öffentlichen Vertrag. Schließlich kann eine final-Klasse nicht erweitert werden. Weil String final ist, lässt sich class ShortString extends String nicht kompilieren.

Ein Konstruktor einer Unterklasse muss die Initialisierung des Oberklassenteils desselben Objekts veranlassen. Er kann einen Oberklassenkonstruktor mit super(...) aufrufen oder mit this(...) an einen anderen Konstruktor seiner eigenen Klasse delegieren.

Wähle den Oberklassenkonstruktor

class Person {
    private final String name;
    Person(String name) { this.name = name; }
}
class Student extends Person {
    private final String studentId;
    Student(String name, String studentId) {
        super(name);
        this.studentId = studentId;
    }
    Student(String name) {
        this(name, "no id yet");
    }
}

Der Konstruktor mit zwei Argumenten übergibt den Namen an Person und speichert die Kennung selbst. Der Konstruktor mit einem Argument delegiert an ihn. Ein Konstruktor enthält höchstens einen expliziten Konstruktoraufruf: this(...) oder super(...). Verfolgst du die this(...)-Kette, erreichst du schließlich einen Konstruktor, der super(...) aufruft.

Steht keiner der beiden Aufrufe im Code, fügt Java super() ein. Das schlägt hier fehl, weil Person nur einen Konstruktor hat, der einen Namen benötigt. Sobald irgendein Konstruktor deklariert wird, stellt Java keinen parameterlosen Standardkonstruktor bereit. Eine Klasse ohne deklarierten Konstruktor erhält einen Standardkonstruktor, der super() aufruft.

new Person(name) innerhalb von Student bewirkt etwas anderes: Es erzeugt ein separates Objekt. Es initialisiert weder den Personenzustand des aktuellen Studenten noch ersetzt es den erforderlichen Aufruf des Oberklassenkonstruktors.

Verfolge die Initialisierung in ihrer Reihenfolge

class Base {
    Base() { System.out.println("Base ready"); }
}
class Middle extends Base {
    Middle() { System.out.println("Middle ready"); }
}
class Top extends Middle {
    Top() { super(); System.out.println("Top ready"); }
}

new Top() durchläuft die Konstruktorkette bis zu Object. Bei der Rückkehr aus den Aufrufen lautet die Ausgabe „Base ready“, „Middle ready“ und dann „Top ready“. Die Feldinitialisierer jeder Klasse werden ausgeführt, nachdem ihr Oberklassenkonstruktor zurückgekehrt ist und bevor der restliche Konstruktorrumpf dieser Klasse ausgeführt wird.

Eine überschreibbare Methode, die ein Oberklassenkonstruktor aufruft, kann bereits eine Überschreibung der Unterklasse ausführen. Liest diese Überschreibung ein Referenzfeld der Unterklasse, dessen Zuweisung noch nicht ausgeführt wurde, sieht sie null, selbst wenn das Feld einen Initialisierer in der Deklaration hat. Beschränke die Arbeit von Konstruktoren auf das Initialisieren des Zustands; vermeide Aufrufe von Methoden, die Unterklassen überschreiben können.

Erkenne die Änderung in Java 25

In Java 25 kann ein Konstruktor Parameter vor seinem expliziten Konstruktoraufruf validieren:

Student(String name, String studentId, int credits) {
    if (credits < 0) {
        throw new IllegalArgumentException("negative credits");
    }
    super(name);
    this.studentId = studentId;
}

Java 25 erlaubt außerdem einfache vorgezogene Zuweisungen an Felder, die in der aktuellen Klasse ohne Initialisierer in der Deklaration definiert sind. Weiterhin verboten ist es, vor dem Aufruf Felder des aktuellen Objekts zu lesen, seine Instanzmethoden aufzurufen oder this weiterzugeben. Bei Standard-Sprachversionen vor Java 25 muss super(...) oder this(...) an erster Stelle stehen. Java 22–24 bot frühere Formen als Vorschaufunktionen an.

Eine Überschreibung gibt einer Unterklasse eine eigene Implementierung einer geerbten Instanzmethode. Ihr Name und ihre Parametertypen stimmen mit der ursprünglichen Methode überein, sodass Aufrufer weiterhin dieselbe Operation verwenden können.

Erweitere eine funktionierende Methode

Angenommen, das Jahresgehalt eines Beschäftigten beträgt zwölf Monatsgehälter. Eine Führungskraft erhält außerdem einen jährlichen Bonus:

class Employee {
    private final double monthlySalary;
    Employee(double monthlySalary) {
        this.monthlySalary = monthlySalary;
    }
    public double yearlyPay() { return 12 * monthlySalary; }
}
class Manager extends Employee {
    private final double bonus;
    Manager(double monthlySalary, double bonus) {
        super(monthlySalary);
        this.bonus = bonus;
    }
    @Override
    public double yearlyPay() {
        return super.yearlyPay() + bonus;
    }
}

Für new Manager(3000.0, 5000.0) gibt der Aufruf der Oberklassenmethode 36.000,0 zurück. Die Addition von 5.000,0 ergibt 41.000,0. super.yearlyPay() wählt ausdrücklich die Implementierung der Oberklasse. Die Oberklassenmethode bleibt innerhalb der Unterklasse verfügbar, obwohl gewöhnliche Aufrufe auf dem Manager die Überschreibung ausführen.

return yearlyPay() + bonus; ruft die eigene Methode des Managers erneut auf. Kein Aufruf wird abgeschlossen, sodass die Ausführung schließlich mit StackOverflowError fehlschlägt. Das fehlende super. ändert die Bedeutung des Aufrufs.

Lass den Compiler die Signatur prüfen

Setze @Override über jede überschreibende Methode. Ein Schreibfehler wie yearlypay() oder ein zusätzlicher Parameter führt dann zu einem Kompilierfehler. Ohne die Annotation akzeptiert Java möglicherweise eine neue Methode, die Aufrufer nie verwenden.

Eine gültige Überschreibung folgt diesen Regeln:

• Ihre Parametertypen stimmen exakt überein.
• Ihr Rückgabetyp ist gleich oder bei der Rückgabe eines Objekttyps ein Untertyp. Diese erlaubte Einengung heißt kovarianter Rückgabetyp.
• Ihr Zugriff ist mindestens so offen wie der Zugriff auf die geerbte Methode.
• Sie fügt keine geprüften Ausnahmen hinzu, die die geerbte Deklaration verbietet.

Zum Beispiel kann public String toString() nicht durch String toString() mit Paketzugriff ersetzt werden. Bestehende Aufrufer müssen den Zugriff behalten.

Unterscheide Überschreiben von Überladen und Verdecken

role() und role(String language) sind überladene Methoden; die zweite ersetzt die erste nicht. Die Auswahl der überladenen Methode erfolgt zur Kompilierzeit anhand der deklarierten Argumenttypen. Auch statische Methoden werden anhand des zur Kompilierzeit verwendeten Typs ausgewählt und daher nicht dynamisch überschrieben.

Eine private Methode wird nicht geerbt; eine gleichnamige Methode der Unterklasse ist unabhängig davon. Eine final-Methode kann nicht überschrieben werden, und Konstruktoren können nicht überschrieben werden. Über die Kompilierbarkeit hinaus muss die Methode weiterhin ihren ursprünglichen Zweck erfüllen. Eine Überschreibung für eine Führungskraft, die das Monatsgehalt zurückgibt, würde Code zur Berechnung von Jahresgehaltssummen unbrauchbar machen, selbst wenn ihre Signatur korrekt wäre.

Jede Java-Klasse erweitert Object direkt oder indirekt. Auch Arrays sind Objekte. Diese gemeinsame Wurzel stellt Methoden wie toString(), equals(Object), hashCode() und getClass() bereit, selbst wenn eine Klasse keine davon deklariert.

Ersetze die ausgegebene Standardbeschreibung

Das geerbte Object.toString() erzeugt einen Klassennamen, @ und den Hashcode des Objekts in hexadezimaler Schreibweise. Ein Text wie „school.Person@1b6d3586“ bezeichnet die Klasse, erläutert aber nicht die Daten der Person. Die Zahl kann sich zwischen Programmläufen ändern und ist keine von Java zugesicherte Speicheradresse.

Eine nützliche Überschreibung zeigt die Felder, die Lesende benötigen. Hier hat ein Student getName() geerbt und speichert ein Feld credits:

@Override
public String toString() {
    return getName() + " (" + credits + " credits)";
}

Für einen Studenten namens Ada Lovelace mit 10 Leistungspunkten gibt System.out.println(s) „Ada Lovelace (10 credits)“ aus. Der Ausgabeaufruf ermittelt den Text des Objekts automatisch. Die String-Konkatenation tut das ebenfalls: "Student: " + s enthält dieselbe Beschreibung.

Bei einer Nullreferenz erzeugen Ausgabe und Konkatenation „null“. Ein expliziter Aufruf s.toString(), wenn s null ist, wirft eine NullPointerException, weil kein Objekt vorhanden ist, das den Aufruf entgegennehmen kann.

Wenn Person.toString() bereits den Namen der Person zurückgibt, kann eine Unterklasse darauf aufbauen:

@Override
public String toString() {
    return super.toString() + ", student id " + studentId;
}

Für die Kennung „S-17“ ergibt das „Ada Lovelace, student id S-17“. Wie nützlich super.toString() ist, hängt davon ab, was die Oberklasse tatsächlich zurückgibt. Verwendet sie noch die Version von Object, steuert sie den Standardtext aus Klasse und Hashcode bei.

Halte Identität und Klasseninformation auseinander

Object.equals(Object) vergleicht die Identität: Die Methode gibt wahr zurück, wenn beide Referenzen auf dasselbe Objekt verweisen. Zwei separate new Person("Ada")-Objekte sind nach dieser geerbten Implementierung trotz übereinstimmender Namen nicht gleich. Klassen wie String, Integer und ArrayList stellen Überschreibungen für den Wertvergleich bereit.

getClass() meldet die tatsächliche Laufzeitklasse:

Person p = new Student("Ada Lovelace");
System.out.println(p.getClass().getSimpleName());

Dies gibt „Student“ aus, wenn Student den gezeigten Konstruktor hat. Der deklarierte Typ der Variablen ändert die Klasse des Objekts nicht. getClass() ist final und kann nicht überschrieben werden.

hashCode() unterstützt hashbasierte Collections. Zu den weiteren Methoden von Object gehören das geschützte clone() und die Methoden zur Koordination von Threads wait(), notify() und notifyAll().

Prüfe die genaue Schreibweise

Java unterscheidet toString() von tostring(). Eine Methode toString(String prefix) ist eine Überladung und wird daher bei der Ausgabe nicht aufgerufen. Beide Fehler werden durch @Override erkannt. Eine Textdarstellung definiert auch keine Gleichheit: Zwei Objekte können denselben Text ausgeben und beim Vergleich dennoch ungleich sein.

Zwei Objekte können denselben Wert darstellen, ohne dasselbe Objekt zu sein. Ein Bücherkatalog kann zwei Buchobjekte als gleich behandeln, wenn ihr Katalogcode und ihre Auflage übereinstimmen. Definiere diese Regel durch Überschreiben von equals(Object) und halte die Hashcode-Berechnung dazu konsistent.

Vergleiche die Felder, die den Wert bestimmen

import java.util.Objects;

final class Book {
    private final String code;
    private final int edition;
    Book(String code, int edition) {
        this.code = code;
        this.edition = edition;
    }
    @Override
    public boolean equals(Object other) {
        if (this == other) return true;
        if (!(other instanceof Book b)) return false;
        return edition == b.edition && Objects.equals(code, b.code);
    }
    @Override
    public int hashCode() {
        return Objects.hash(code, edition);
    }
}

Die Identitätsprüfung akzeptiert dasselbe Objekt schnell. Die Typprüfung lehnt ein nicht verwandtes Objekt oder null ab und führt dann b als Book ein. Für die primitiven Auflagenwerte wird == verwendet; Objects.equals vergleicht Codes auch dann sicher, wenn ein Code null ist. Zwei Bücher mit dem Code „B-1042“ und der Auflage 2 gelten als gleich. Auflage 3 ergibt einen anderen Wert.

Der Parameter muss Object sein. equals(Book other) fügt eine Überladung hinzu und belässt das geerbte equals(Object). Bibliothekscode, der diese Signatur aufruft, würde weiterhin die Identität vergleichen. @Override lässt die falsche Deklaration bei der Kompilierung fehlschlagen.

Halte die Gleichheitszusagen ein

Für Referenzen, die nicht null sind, muss Gleichheit folgende Eigenschaften haben:

• Reflexiv: Ein Objekt ist gleich sich selbst.
• Symmetrisch: Das Vertauschen der beiden Objekte ergibt dieselbe Antwort.
• Transitiv: Ist das erste gleich dem zweiten und das zweite gleich dem dritten, ist das erste gleich dem dritten.
• Konsistent: Wiederholte Vergleiche stimmen überein, solange die verglichenen Daten unverändert bleiben.

Ein Objekt muss beim Vergleich mit null außerdem ungleich sein. Gleiche Objekte müssen gleiche Hashcodes zurückgeben. Ungleiche Objekte dürfen denselben Hashcode haben: Eine Hashkollision belegt keine Gleichheit. Leite den Hashcode aus denselben Feldern wie die Gleichheit ab, wie es hier Objects.hash(code, edition) tut.

Eine Hash-Collection verwendet den Hashcode, um Kandidaten zu finden, bevor sie deren Gleichheit prüft. Wird nur equals überschrieben, kann eine Menge separate gleiche Bücher behalten oder eine Map einen gleichen Schlüssel nicht finden. Wird ein für den Hashcode verwendetes Feld geändert, während das Objekt als Schlüssel gespeichert ist, kann das Objekt unter seinem alten Hashcode abgelegt bleiben.

Schütze die Symmetrie über Unterklassen hinweg

Angenommen, eine erweiterbare Klasse Book akzeptiert jedes instanceof Book, während Ebook die Dateigröße in den Gleichheitsvergleich aufnimmt und nur E-Books akzeptiert. Ein Buch kann ein E-Book mit demselben Code und derselben Auflage akzeptieren, aber das E-Book lehnt das Buch ab. Der Vergleich ist nicht mehr symmetrisch.

Ein Ansatz verlangt übereinstimmende Laufzeitklassen und prüft vor getClass() auf null. Ein anderer macht die Gleichheitsmethode der Oberklasse final, sodass Unterklassen die Gleichheitsregel nicht erweitern können. Eine finale Werteklasse wie oben vermeidet Unterklassen und damit auch deren Gleichheitsvergleich. Records erzeugen Gleichheitsvergleich und Hashcode-Berechnung aus ihren Komponenten; Aufzählungskonstanten besitzen bereits einen identitätsbasierten Gleichheitsvergleich, der zu ihren festen Werten passt.

Eine abstrakte Klasse ist eine Basisklasse, die nicht direkt instanziiert werden kann. Sie kann gemeinsame Felder und funktionierende Methoden enthalten und zugleich ausgewählte Operationen den Unterklassen zur Vervollständigung überlassen.

Lass eine erforderliche Operation abstrakt

abstract class Shape {
    private final String name;
    Shape(String name) { this.name = name; }
    public abstract double area();
    public String describe() {
        return name + " with area " + area();
    }
}
class Rectangle extends Shape {
    private final double width;
    private final double height;
    Rectangle(double width, double height) {
        super("rectangle");
        this.width = width;
        this.height = height;
    }
    @Override
    public double area() { return width * height; }
}

area() hat eine Signatur und ein Semikolon, aber keinen Rumpf. Die Methode legt fest, was jede konkrete Form bereitstellen muss. Weil Shape eine abstrakte Methode enthält, muss auch die Klasse abstrakt sein. Rectangle stellt die fehlende Implementierung bereit und kann instanziiert werden.

Für new Rectangle(3.0, 4.0) speichert der Oberklassenkonstruktor „rectangle“. Der Konstruktor der Unterklasse speichert die Abmessungen. Die Fläche beträgt 12,0 Quadratmeter, wenn die Abmessungen in Metern angegeben sind. Der Aufruf von describe() gibt „rectangle with area 12.0“ zurück. Der Aufruf von area() in der geerbten Methode führt die Implementierung des Rechtecks aus.

Verwende Konstruktoren und konkrete Methoden wie gewohnt

Eine abstrakte Klasse kann Felder, Konstruktoren und Methoden mit Rumpf sowie den üblichen Zugriffsstufen haben. Ihr Konstruktor wird als Teil der Erzeugung eines Unterklassenobjekts ausgeführt. new Shape() ist selbst dann verboten, wenn ein passender Konstruktor existiert; new Rectangle(3.0, 4.0) ist gültig.

Eine zweite Unterklasse kann dieselbe geerbte Beschreibung verwenden und die Fläche anders berechnen. Eine Implementierung für einen Kreis gibt Math.PI * radius * radius zurück. Bei einem Radius von 1,5 m lautet die Rechnung π mal 2,25, also etwa 7,07 Quadratmeter. Die gemeinsam genutzte Methode describe() braucht keinen kreisspezifischen Zweig.

Eine Variable kann weiterhin den abstrakten Typ haben: Shape s = new Rectangle(3.0, 4.0);. Java verbietet die Erzeugung der abstrakten Klasse, nicht den Verweis auf ein konkretes Objekt über diesen Typ.

Mache fehlende Implementierungen zum Kompilierfehler

Jede konkrete Unterklasse muss Implementierungen aller abstrakten Methoden bereitstellen oder erben. Eine Unterklasse, die einige davon unvollendet lässt, muss ebenfalls als abstrakt deklariert werden. Würde ein Platzhalter area() den Wert 0 zurückgeben, ließe sich eine unvollständige konkrete Unterklasse kompilieren und würde unbemerkt falsche Ergebnisse liefern. Deklarierst du area() als abstrakt, wird die fehlende Implementierung für den Compiler sichtbar.

Abstrakte Methoden können nicht private, static oder final sein: Jede dieser Festlegungen würde die Überschreibung in der Unterklasse verhindern, die die Operation bereitstellt. Eine abstrakte Klasse kann auch keine abstrakten Methoden enthalten; der Modifikator verhindert dann nur die direkte Erzeugung. Verwende diese Art von Basisklasse, wenn ihre Unterklassen den Ist-ein-Test bestehen und von gemeinsamem Zustand oder Code profitieren.

Ein Interface benennt eine Fähigkeit, die mehrere Klassen bereitstellen können. Es legt die Methoden fest, die über diese Fähigkeit verfügbar sind, ohne zu verlangen, dass die Klassen dieselben Instanzfelder oder dieselbe Oberklasse haben.

Deklariere und implementiere die Methoden

interface Chargeable {
    int batteryPercent();
    void charge(int minutes);
}
class Phone implements Chargeable {
    private int battery;
    Phone(int battery) { this.battery = battery; }
    @Override
    public int batteryPercent() { return battery; }
    @Override
    public void charge(int minutes) {
        battery = Math.min(100, battery + 2 * minutes);
    }
}

Die abstrakten Methoden des Interfaces sind implizit public. Die implementierenden Methoden müssen ausdrücklich public sein; das Weglassen dieses Modifikators würde den Zugriff einschränken und zu einem Kompilierfehler führen. Eine konkrete Klasse muss für jede abstrakte Methode eine geeignete öffentliche Implementierung bereitstellen oder erben. Eine abstrakte implementierende Klasse darf einige davon ihren Unterklassen überlassen.

Bei einem Telefon mit 35 % Ladung fügt charge(20) 40 Prozentpunkte hinzu und ergibt 75 %. Weitere 20 Minuten würden vor der Begrenzung 115 ergeben, daher speichert Math.min den Wert 100. Ein ElectricScooter kann dasselbe Interface implementieren und dabei nur einen Punkt pro Minute hinzufügen: Ausgehend von 50 % erreicht er nach 20 Minuten 70. Das Interface legt die verfügbare Operation fest, während die Klasse deren Verhalten bereitstellt.

Verwende das Interface als Typ

Chargeable device = new Phone(35);
device.charge(20);
System.out.println(device.batteryPercent());

Dies gibt 75 aus. Aufrufender Code kann die Methoden des Interfaces und die öffentlichen Methoden verwenden, die auf jedem Objekt verfügbar sind. Operationen, die nur das Telefon bietet, sind über device nicht verfügbar, sofern das deklarierte Interface sie nicht bereitstellt.

Interfaces können auch Typen von Parametern, Rückgabewerten und Listenelementen sein. Eine Methode, die Chargeable akzeptiert, kann mit einem Telefon oder einem Roller arbeiten, ohne deren Feldstruktur zu kennen. Die Java-Bibliothek verwendet denselben Ansatz: List hat Implementierungen wie ArrayList und LinkedList; Runnable deklariert run(); Comparable deklariert den natürlichen Vergleich.

Kombiniere mehrere Fähigkeiten

Eine Klasse erweitert eine Klasse und kann mehrere Interfaces implementieren. Die Reihenfolge lautet class Phone extends Device implements Chargeable, Connectable. Ein Interface kann mehrere Interfaces erweitern: interface SmartDevice extends Chargeable, Connectable. Implementierende Klassen müssen dann alle geerbten abstrakten Operationen bereitstellen.

Ein Interface hat keine Konstruktoren und keine Instanzfelder. new Chargeable() lässt sich nicht kompilieren. Ein deklariertes Feld wie int FULL = 100; ist implizit eine public static final-Konstante, auf die mit Chargeable.FULL zugegriffen wird.

Eine abstrakte Interface-Methode liefert keinen funktionsfähigen Code. Ihre Implementierung kann aus der Klasse selbst oder einer geerbten öffentlichen Oberklassenmethode stammen. Default-Methoden sind diejenigen Interface-Methoden, die geerbtes Instanzverhalten bereitstellen können.

Interfaces können neben abstrakten Methodendeklarationen auch funktionsfähigen Code bereitstellen. Der Modifikator einer Methode entscheidet, ob implementierende Objekte sie erben, ob aufrufender Code den Interface-Namen verwendet oder ob nur Code innerhalb des Interfaces sie verwenden kann.

Baue Default-Verhalten aus dem Vertrag auf

interface Chargeable {
    int batteryPercent();
    void charge(int minutes);
    default boolean needsCharge() {
        return batteryPercent() < 20;
    }
    static int clamp(int percent) {
        return Math.max(0, Math.min(100, percent));
    }
}

Eine Default-Methode ist eine öffentliche Instanzmethode mit einem Rumpf. Ein Telefon, das 15 % meldet, erbt needsCharge() und gibt wahr zurück. Bei 20 % gibt es falsch zurück. Die Default-Methode ruft die abstrakte Operation batteryPercent() auf; sie liest kein privates Feld eines Telefons. Eine Klasse darf die Methode mit einer eigenen öffentlichen Implementierung überschreiben.

Eine statische Interface-Methode gehört zum Interface: Chargeable.clamp(130) gibt 100 und Chargeable.clamp(-5) gibt 0 zurück. Implementierende Klassen erben sie nicht, daher ist Phone.clamp(130) kein gültiger Aufruf dieser Methode. Default- und statische Interface-Methoden wurden in Java 8 eingeführt.

Seit Java 9 kann ein Interface auch private Methoden deklarieren, um Hilfscode zwischen seinen eigenen Methoden zu teilen. Eine private Instanzhilfsmethode unterstützt Default-Methoden; eine private statische Hilfsmethode kann auch statische Methoden unterstützen. Implementierende Klassen können diese Hilfsmethoden nicht direkt aufrufen.

Löse Konflikte zwischen Default-Methoden

Zwei nicht verwandte Interfaces können dieselbe Signatur bereitstellen:

interface Lamp {
    default String describe() { return "lamp"; }
}
interface Speaker {
    default String describe() { return "speaker"; }
}
class SmartLamp implements Lamp, Speaker {
    @Override
    public String describe() {
        return Lamp.super.describe() + " and "
             + Speaker.super.describe();
    }
}

Ohne die Überschreibung hat SmartLamp einen Konflikt und lässt sich nicht kompilieren. Die qualifizierten Aufrufe InterfaceName.super.method() wählen die einzelnen Default-Methoden aus den direkten Oberinterfaces aus. Diese Implementierung gibt „lamp and speaker“ zurück.

Auch eine abstrakte Deklaration in der Oberklasse kann eine konkrete Unterklasse verpflichten, die Methode zu implementieren; eine Interface-Default-Methode hebt diese Pflicht nicht auf.

Berücksichtige bestehende implementierende Klassen

Das Hinzufügen einer abstrakten Methode verlangt von jeder konkreten implementierenden Klasse, eine passende Implementierung bereitzustellen oder zu erben. Eine Default-Methode vermeidet diese Änderung oft, indem sie funktionsfähiges Verhalten bereitstellt, kann aber einen Konflikt mit einer anderen geerbten Methode verursachen. Default-Methoden helfen bei der Weiterentwicklung eines Interfaces; die Vererbungsregeln bestimmen weiterhin, ob sich die entstehenden Klassen kompilieren lassen.

Sowohl eine abstrakte Klasse als auch ein Interface können erforderliche Methoden definieren. Die Wahl hängt von der Beziehung zwischen den Objekten ab und davon, ob ihre Implementierung gemeinsamen Instanzzustand benötigt.

Vergleiche, was beide bereitstellen

Interface-Felder sind public static final-Konstanten, keine Daten einzelner Objekte. Private Interface-Hilfsmethoden unterstützen die eigenen funktionsfähigen Methoden des Interfaces; sie erzeugen keinen privaten Zustand für jedes implementierende Objekt.

Lege eng verwandten Zustand in einer abstrakten Klasse ab

Ein Zeichenprogramm hat Kreise, Rechtecke und Dreiecke. Jede Form speichert einen Namen und eine Position, und jede berechnet ihre Fläche anders. Eine abstrakte Klasse Shape kann die gemeinsamen Felder und den Konstruktor verwalten, funktionsfähige Methoden zum Bewegen oder Beschreiben bereitstellen und area() als abstrakt deklarieren.

Alle konkreten Formen sind Arten von Shape, sodass anderer Code eine Form anfordern und jede davon erhalten kann. Ebenso könnte eine abstrakte Klasse Enemy Lebenspunkte und eine gemeinsame Methode takeDamage(int points) verwalten und die Bewegung den jeweiligen Gegnerklassen überlassen. Der gemeinsame Zustand gibt diesen Basisklassen sinnvolle Aufgaben.

Lege eine klassenübergreifende Fähigkeit in einem Interface fest

Dasselbe Zeichenprogramm kann Formen, Textbeschriftungen und Bilder exportieren. Durch den Export wird eine Textbeschriftung nicht zu einer Form, und diese Objekte benötigen möglicherweise bereits unterschiedliche Oberklassen. Ein Interface Exportable kann String exportText() deklarieren. Jede Klasse implementiert die Operation mit ihren eigenen Daten.

Eine Klasse kann beide Rollen kombinieren: class Circle extends Shape implements Exportable. Die Oberklasse stellt den Zustand der Form und gemeinsamen Code bereit; das Interface macht den Kreis für Exportcode verwendbar. Eine Klasse, die mehrere Interfaces implementiert, sichert mehrere Fähigkeiten zu, ohne Instanzfelder von ihnen zu erben.

Kombiniere einen Vertrag mit einer Teilimplementierung

Eine abstrakte Klasse kann ein Interface implementieren und nur einige Methoden vervollständigen. Konkrete Unterklassen erledigen die übrigen Operationen. Java verwendet diese Anordnung bei List und AbstractList; ArrayList erweitert AbstractList. Aufrufender Code kann sich auf das Interface stützen, während Implementierungen eine Basisklasse wiederverwenden, wo sie passt.

Zum Beispiel ermöglicht List<String> names = new ArrayList<>(); aufrufendem Code, Namen über List hinzuzufügen, zu lesen und zu entfernen. Wird der Initialisierer durch new LinkedList<>() ersetzt, bleiben diese Aufrufe erhalten. Ein als ArrayList<String> deklarierter Parameter würde eine LinkedList<String> ablehnen, selbst wenn er nur Listenoperationen benötigt.

Eine abstrakte Klasse, die nur abstrakte Methoden enthält, belegt weiterhin den einzigen Oberklassenplatz der Unterklasse. Sie ist nicht mit einem Interface austauschbar. Wähle das Interface, wenn nur der gemeinsame Vertrag benötigt wird, und ergänze eine Basisklasse, wenn verwandte Implementierungen von gemeinsamem Zustand oder Code profitieren.

Polymorphie ermöglicht es einer allgemeinen Referenz, auf Objekte verschiedener Untertypen zu verweisen. Das Objekt behält seinen vollständigen Zustand und sein Verhalten; die Referenz gibt aufrufendem Code eine bestimmte Sicht auf die verfügbaren Operationen.

Benenne die beiden Typen

Person p = new Student("Ada Lovelace", "S-17");

Der deklarierte Typ, auch statischer Typ genannt, ist Person: Er steht in der Variablendeklaration. Der dynamische Typ oder Laufzeittyp ist Student: Das ist die Klasse, die mit new instanziiert wird. Die tatsächliche Klasse des Objekts ändert sich nach seiner Erzeugung nicht.

Die Zuweisung einer Studentenreferenz an eine Personenreferenz ist ein Upcast. Er erfolgt automatisch und ist sicher, weil jeder Student eine Person ist. Auf denselben Studenten kann auch eine Variable vom Typ Object verweisen. Ein implementierendes Objekt kann per Upcast einem Interface zugewiesen werden, das es implementiert, wie in Chargeable c = new Phone(35);.

Durch die Zuweisung werden keine Studentendaten gelöscht. Es gibt weiterhin ein Studentenobjekt mit seiner Studentenkennung, geerbten Personendaten und überschriebenen Methoden. Eine allgemeinere Referenz ändert, welche Zugriffe der Compiler über diese Referenz erlaubt.

Prüfe Aufrufe anhand des deklarierten Typs

Wenn Person die Methode getName() deklariert, lässt sich p.getName() kompilieren. Wenn nur Student die Methode getStudentId() deklariert, lässt sich p.getStudentId() nicht kompilieren. Der Compiler prüft die Schnittstelle von Person, selbst wenn der Initialisierer eindeutig einen Studenten erzeugt.

Die umgekehrte Zuweisung Student s = p; wird ohne explizite Typumwandlung nicht akzeptiert. Eine Personenreferenz könnte auf eine Person verweisen, die kein Student ist. Diese Einschränkung schützt Code davor, ein Objekt als einen Untertyp zu behandeln, den es nicht hat.

Lass Parameter und Listen mehrere Untertypen akzeptieren

Eine Methode static void printCard(Person person) kann ein Objekt vom Typ Person, Student oder Teacher erhalten, sofern die beiden letzten Person erweitern. Ihr Code kann sich auf den Vertrag von Person stützen. Auch ein Rückgabetyp kann allgemein sein, zum Beispiel bei einer Methode, die ein Shape zurückgibt.

Eine Liste mit einem allgemeinen Elementtyp kann verschiedene Formklassen speichern:

List<Shape> shapes = new ArrayList<>();
shapes.add(new Circle(1.5));
shapes.add(new Rectangle(3.0, 4.0));
for (Shape shape : shapes) {
    System.out.println(shape.area());
}

Hier stammen List und ArrayList aus java.util, und jede konkrete Form stellt area() bereit. Die Schleife verwendet nur diese gemeinsame Operation.

Eine List<Circle> ist keine List<Shape>. Wäre sie es, könnte Code, der sie als Formliste erhält, ein Rechteck zu einer Liste hinzufügen, die nur Kreise enthalten soll. Wenn eine Methode List<Shape> verlangt, erstelle die Liste von Anfang an mit diesem Elementtyp.

Ein Methodenaufruf wird in zwei Phasen aufgelöst. Zur Kompilierzeit prüft Java die deklarierten Typen und wählt eine Methodensignatur. Zur Laufzeit wählt die dynamische Bindung die überschreibende Instanzmethodenimplementierung für die tatsächliche Klasse des Objekts.

Verfolge einen Aufruf innerhalb einer geerbten Methode

class A {
    String who() { return "A"; }
    String hello() { return "Hello from " + who(); }
}
class B extends A {
    @Override String who() { return "B"; }
}
class C extends B { }

Für A x = new C(); ist x.hello() erlaubt, weil A die Methode hello() deklariert. Weder Klasse C noch B überschreibt hello(), daher führt Java die Implementierung in A aus.

Innerhalb dieser Methode bedeutet who() dasselbe wie this.who(). Das Empfängerobjekt ist weiterhin das C-Objekt. Java sucht von C aus und findet dann die nächstgelegene who()-Implementierung in B. Das Ergebnis ist „Hello from B“. Der Eintritt in eine geerbte Methode verwandelt das Empfängerobjekt nicht in ein Objekt der Oberklasse.

Wähle eine Überladung vor einer Überschreibung

static String kind(Object value) { return "object"; }
static String kind(String value) { return "string"; }

Innerhalb einer Klasse, die diese Methoden enthält, wählt Object value = "hi"; kind(value) die Methode kind(Object) und gibt „object“ zurück. Der deklarierte Typ der Variablen ist Object; Java prüft die Überladungen zur Laufzeit nicht anhand des tatsächlichen Strings erneut.

Bei einem Instanzaufruf kann die Laufzeitbindung weiterhin eine Überschreibung der bereits gewählten Signatur auswählen. Sie kann nicht zu einer anderen Überladung wechseln, die für das tatsächliche Argument lediglich spezifischer aussieht. Bestimme zuerst die Signatur und suche dann nach ihrer Überschreibung.

Erkenne Aufrufe und Mitglieder ohne diese Bindung

Wenn P das Feld String label = "P"; deklariert und Q extends P ein eigenes String label = "Q"; deklariert, liest P p = new Q(); p.label den Wert „P“. Felder werden verdeckt, nicht überschrieben. Beide Felder existieren im Objekt. Vermeide es, geerbte Feldnamen erneut zu verwenden, weil gleich aussehende Zugriffe je nach Referenztyp unterschiedliche Zustände lesen können.

super.method() wählt die Implementierung der Oberklasse, einschließlich einer Implementierung, die diese Oberklasse erbt. Wenn die gewählte Methode selbst einen gewöhnlichen Aufruf auf this ausführt, kann dieser innere Aufruf weiterhin an eine Überschreibung der Unterklasse gebunden werden.

Eine allgemeine Referenz benötigt manchmal Zugriff auf eine Operation, die nur zu einem Untertyp gehört. Ein Downcast weist den Compiler an, die Referenz als diesen Untertyp zu behandeln. Zur Laufzeit prüft Java, ob das Objekt bereits diesen Typ hat.

Verstehe, was eine explizite Typumwandlung ändert

Angenommen, Person p verweist auf einen Studenten. Student s = (Student) p; erlaubt s.getStudentId(). Beide Variablen verweisen weiterhin auf dasselbe Objekt. Die Typumwandlung kopiert es nicht, ändert seine tatsächliche Klasse nicht und fügt einer einfachen Person keine Studentenfelder hinzu.

Wenn p tatsächlich auf new Person("Grace Hopper") verweist, wirft diese Typumwandlung eine ClassCastException. Der Compiler akzeptiert die mögliche Beziehung von Person zu Student, aber das Laufzeitobjekt muss sie auch erfüllen. Eine Typumwandlung zwischen Klassen, die nicht verwandt sein können, etwa die Umwandlung einer Person-Referenz in die finale Klasse Integer, schlägt zur Kompilierzeit fehl.

Das unterscheidet sich von einer Umwandlung primitiver Werte: (int) 3.9 erzeugt den Ganzzahlwert 3. Eine explizite Umwandlung einer Referenz prüft und ändert nur den Typ, über den eine bestehende Referenz verwendet wird.

Verbinde die Prüfung mit der neuen Variablen

Seit Java 16 macht die Mustererkennung den sicheren Fall kurz:

static void showStudentId(Person person) {
    if (person instanceof Student student) {
        System.out.println(student.getStudentId());
    }
}

Die Prüfung ist für einen Studenten oder ein Objekt einer Unterklasse von Student wahr. Die Variable student ist innerhalb des Blocks verfügbar, wo bekannt ist, dass die Prüfung erfolgreich war. Eine einfache Person überspringt den Block. Auch eine Nullreferenz macht die Prüfung falsch, sodass der Block nie versucht, eine Methode auf null aufzurufen.

Die ältere Form prüft person instanceof Student und deklariert dann Student student = (Student) person; innerhalb des erfolgreichen Zweigs. Beide Formen sichern die Typumwandlung ab. Die Prüfung eines anderen Objekts an anderer Stelle sichert eine Typumwandlung von person nicht ab; Prüfung und Typumwandlung müssen dieselbe Referenz betreffen.

Ein Upcast benötigt keine explizite Typumwandlung. Person person = student; lässt sich bereits kompilieren und kann nicht wegen eines unpassenden Typs fehlschlagen. Eine Umwandlung von null in einen kompatiblen Referenztyp ergibt null; wird das Ergebnis für einen Instanzmethodenaufruf verwendet, schlägt dies weiterhin mit einer NullPointerException fehl.

Entscheide, ob ein Typtest nötig ist

Typtests eignen sich für Code, der ein Object erhält, etwa equals(Object other), oder eine Operation benötigt, die nur ein Untertyp bietet, etwa eine Studentenkennung. Sie können auch bei der Arbeit mit Klassen helfen, die nicht geändert werden können.

Eine wiederholte Kette von Typtests für eine gemeinsame Operation ist ein anderes Problem. Prüft Code jede Formklasse, um ihre Fläche zu berechnen, benötigt jede hinzugefügte Form einen weiteren Zweig. Wird area() in Shape deklariert und von den Unterklassen implementiert, kann aufrufender Code stattdessen shape.area() verwenden.

Eine explizite Typumwandlung kann eine fehlende gemeinsame Operation nicht für jeden Untertyp verfügbar machen. Lege gemeinsames Verhalten im gemeinsamen Vertrag fest und verwende einen Untertyptest für Aufgaben, die tatsächlich diesen bestimmten Untertyp benötigen.

Eine Methode bleibt für neue Klassen nützlich, wenn ihr Parameter genau die Operationen bereitstellt, die sie benötigt. Aufrufender Code liefert Objekte; die dynamische Bindung liefert deren individuelles Verhalten.

Addiere Flächen ohne klassenspezifische Zweige

static double totalArea(List<Shape> shapes) {
    double total = 0;
    for (Shape shape : shapes) {
        total += shape.area();
    }
    return total;
}

Bei einem Kreis mit Radius 1,5 m, einem Rechteck mit den Abmessungen 3,0 m und 4,0 m und einem Dreieck mit Grundseite 4,0 m und Höhe 2,5 m betragen die Flächen etwa 7,06858; 12,0 und 5,0 Quadratmeter. Die Addition der ungerundeten Kreisfläche ergibt etwa 24,07 Quadratmeter. Jedes Objekt stellt sein eigenes area() bereit.

Das Hinzufügen einer Klasse Triangle erfordert keine Änderung der Schleife. Die neue Klasse implementiert die bestehende Formoperation. Ein negatives Ergebnis würde den Flächenvertrag verletzen, selbst wenn die Überschreibung kompiliert; allgemeiner Code verlässt sich sowohl auf die Bedeutung der Operation als auch auf ihre Signatur.

Derselbe Ansatz funktioniert mit einem Interface. Eine Methode chargeAll(List<Chargeable> devices, int minutes) durchläuft Geräte und ruft device.charge(minutes) auf. Nach 20 Minuten erreicht das Telefon, das bei 35 % beginnt, 75 %, und der Roller, der bei 50 % beginnt, erreicht 70 %. Die Schleife wählt selbst nie eine Laderegel aus.

Lass aufrufenden Code eine Listenimplementierung wählen

Ein Parameter List<Shape> akzeptiert sowohl eine ArrayList<Shape> als auch eine LinkedList<Shape>. Ein Parameter ArrayList<Shape> lehnt die verkettete Liste ab, obwohl nur Listenoperationen benötigt werden. Verwende den allgemeinsten Typ, der die benötigten Methoden bereitstellt; alles als Object zu deklarieren wäre zu allgemein, weil diesem Typ area() und Listenoperationen fehlen.

Mache Objekte mit Comparable sortierbar

Comparable<T> definiert die natürliche Ordnung eines Objekts. Das Ergebnis von compareTo ist negativ, wenn dieses Objekt vor dem anderen steht, null bei einem Gleichstand in der Ordnung und positiv, wenn es danach steht. Das Vorzeichen des Ergebnisses ist entscheidend; es muss nicht genau −1 oder 1 sein.

record Runner(String name, int seconds)
        implements Comparable<Runner> {
    @Override
    public int compareTo(Runner other) {
        return Integer.compare(seconds, other.seconds);
    }
}

Eine modifizierbare Liste mit Mia bei 3.605 s, Ken bei 3.490 s und Ana bei 3.720 s ergibt nach Collections.sort(runners) die Reihenfolge Ken, Mia, Ana. Auch list.sort(null) verwendet die natürliche Ordnung. Erstelle eine modifizierbare Liste mit new ArrayList<>(List.of(...)); der Versuch, das nicht modifizierbare Ergebnis von List.of(...) zu sortieren, wirft eine UnsupportedOperationException.

Verwende Integer.compare, statt die Werte zu subtrahieren. Die Subtraktion kann bei großen Werten mit unterschiedlichen Vorzeichen überlaufen und das falsche Vorzeichen zurückgeben. Dieselbe Idee gilt für Double.compare bei Dezimalfeldern. In diesem Läuferbeispiel ergeben gleiche Zeiten einen Gleichstand in der Ordnung, selbst wenn die Namen unterschiedlich sind. Ein Gleichstand beim Vergleich und Objektgleichheit müssen daher nicht dasselbe bedeuten. Bevorzuge eine natürliche Ordnung, deren Ergebnis null mit der Gleichheit übereinstimmt; dokumentiere eine beabsichtigte Abweichung.

Ein Aufzählungstyp gibt einer festen Menge benannter Auswahlmöglichkeiten einen eigenen Typ. enum Size { SMALL, MEDIUM, LARGE } erlaubt Size size = Size.MEDIUM;. Er verhindert, dass aufrufender Code den falsch geschriebenen String „MEDUIM“ oder die Ganzzahl 7 an eine Methode übergibt, die Size verlangt.

Verwende Namen, Konstanten und switch

Jede Aufzählungskonstante ist ein einzelnes Objekt, daher ist size == Size.LARGE ein geeigneter Vergleich. Eine Variable eines Aufzählungstyps kann auch null sein. Size.values() gibt alle Konstanten in der Reihenfolge ihrer Deklaration zurück; Size.valueOf("LARGE") findet den exakt passenden Namen. Bei der Suche wird die Groß- und Kleinschreibung beachtet: „large“ verursacht eine IllegalArgumentException.

name() gibt den deklarierten Namen zurück. ordinal() gibt die Position ab null zurück, daher ist Size.MEDIUM.ordinal() gleich 1. Das Einfügen einer Konstante ändert spätere Positionen, daher eignet sich ein Ordinalwert schlecht als gespeicherter Code oder Geschäftswert. Standardmäßig gibt auch toString() den Namen zurück.

Ein switch-Ausdruck, seit Java 14 Standard, kann einen Wert zurückgeben:

String label = switch (size) {
    case SMALL -> "S";
    case MEDIUM -> "M";
    case LARGE -> "L";
};

Durch das Nennen jeder Konstante ist der Ausdruck ohne default-Zweig vollständig. Diese Fälle setzen voraus, dass size nicht null ist; das Auflisten der Konstanten behandelt null nicht.

Gib jeder Konstante aussagekräftige Daten

enum CupSize {
    SMALL(250), MEDIUM(350), LARGE(500);
    private final int milliliters;
    CupSize(int milliliters) { this.milliliters = milliliters; }
    public int milliliters() { return milliliters; }
}

Das Semikolon trennt die Konstantenliste von den Mitgliedern. Der Konstruktor wird bei der Initialisierung des Aufzählungstyps einmal für jede Konstante ausgeführt. Er ist implizit privat, und aufrufender Code kann mit new CupSize(400) keine neuen Konstanten erzeugen.

Zwei große und ein kleiner Becher fassen 1.250 mL oder 1,25 L. Diese Rechnung verwendet das Feld milliliters, nicht die Positionen der Konstanten. Das Durchlaufen von CupSize.values() und die Ausgabe jeder Konstante mit ihrem Fassungsvermögen ergeben „SMALL: 250 mL“, „MEDIUM: 350 mL“ und „LARGE: 500 mL“.

Gib Konstanten eigenes Verhalten

Ein Aufzählungstyp kann ein Interface implementieren und einzelnen Konstanten unterschiedliche Methodenrümpfe geben:

enum Operation {
    ADD { int apply(int a, int b) { return a + b; } },
    MULTIPLY { int apply(int a, int b) { return a * b; } };
    abstract int apply(int a, int b);
}

Operation.MULTIPLY.apply(6, 7) gibt 42 zurück. Jede Konstante vervollständigt die abstrakte Operation. Aufzählungstypen erweitern implizit java.lang.Enum; sie können keine andere Klasse erweitern, und gewöhnliche Klassen können sie nicht erweitern.

Verwende einen Aufzählungstyp für Auswahlmöglichkeiten, die beim Schreiben des Programms feststehen, etwa Richtungen oder Bestellzustände. Die veränderliche Produktliste eines Geschäfts gehört in Daten: Das Hinzufügen von Produkten sollte nicht verlangen, eine Deklaration des Aufzählungstyps neu zu schreiben und zu kompilieren.

Ein Record ist eine kompakte Datenklasse, die seit Java 16 zum Standard gehört. Sein Kopf listet die Werte auf, die jede Instanz bestimmen und Komponenten heißen: record Point(int x, int y) { }.

Verwende die generierten Mitglieder

Der Compiler stellt für jede Komponente ein privates finales Feld, einen kanonischen Konstruktor mit diesen Komponenten in ihrer Reihenfolge und nach ihnen benannte öffentliche Zugriffsmethoden bereit. Außerdem stellt er equals, hashCode und toString auf Grundlage der Komponenten bereit.

Point a = new Point(3, 4);
Point b = new Point(3, 4);
System.out.println(a.x());
System.out.println(a.equals(b));
System.out.println(a == b);

Dies gibt 3, true und false in getrennten Zeilen aus. Übereinstimmende Komponentenwerte machen die Records gleich, aber die beiden new-Ausdrücke erzeugen separate Objekte. Gleiche Records haben gleiche Hashcodes. Ihr nützlicher generierter Text enthält die Namen des Records und der Komponenten; aktuelle JDKs zeigen „Point[x=3, y=4]“. Dieses genaue Textformat ist nicht garantiert, daher solltest du es nicht als Datenformat parsen.

Die Zugriffsmethoden heißen x() und y(), nicht getX() und getY(). Ein Setter, der this.x = x zuweist, lässt sich nicht kompilieren, weil das Komponentenfeld final ist. Eine Methode kann stattdessen einen neuen Wert zurückgeben: Point moveRight(int dx) { return new Point(x + dx, y); }.

Validiere in einem kompakten Konstruktor

record Temperature(double celsius) {
    Temperature {
        if (celsius < -273.15) {
            throw new IllegalArgumentException("below absolute zero");
        }
    }
}

Ein kompakter Konstruktor wiederholt den Namen des Records ohne Parameterliste. Er prüft oder normalisiert die eingehenden Parameter; Java weist die Komponentenfelder nach seinem Rumpf zu. Diese Prüfung lehnt −300 °C ab und akzeptiert 21,5 °C. Eine Textkomponente könnte vor der automatischen Zuweisung mit name = name.trim(); normalisiert werden.

Ein öffentlicher Record benötigt einen öffentlichen kompakten Konstruktor. Records dürfen außerdem statische Felder, statische Methoden und Instanzmethoden deklarieren. Ein zusätzlicher Konstruktor delegiert mit this(...) an den kanonischen Konstruktor. Zusätzliche Instanzfelder über die Komponenten hinaus sind verboten.

Schütze veränderliche Komponentenobjekte

Finale Komponentenfelder machen die Unveränderlichkeit flach. Ein Record, der eine veränderliche Liste enthält, verweist weiterhin auf diese Liste:

record Team(String name, List<String> members) {
    Team {
        members = List.copyOf(members);
    }
}

Wenn java.util.List importiert ist, speichert dies eine nicht modifizierbare Kopie. Spätere Ergänzungen der ursprünglichen Liste wirken sich nicht auf die Teammitglieder aus, und team.members().add("Lee") wirft eine UnsupportedOperationException. Die Kopie schützt die Listenstruktur; sie macht veränderliche Elementobjekte nicht tiefgehend unveränderlich.

Records erweitern implizit java.lang.Record und sind final. Sie können keine andere Klasse erweitern oder selbst erweitert werden, aber Interfaces wie Comparable implementieren. Verwende sie für Daten, die durch ihre Werte bestimmt sind; verwende eine gewöhnliche Klasse für veränderlichen Zustand, zusätzliche verborgene Instanzfelder oder eine erweiterbare Klassenhierarchie.