1591 Views Kommentare [] 1 0

credit: ©Wilfred/ stock.adobe

Java Blog

Zugriffsstufen beim Methodenüberschreiben

Methoden korrekt zu überschreiben will gelernt sein. Wir sehen uns in diesem Blog-Beitrag einen Spezialfall zu diesem Thema an und erklären das Zusammenspiel zwischen den Zugriffsstufen und dem Überschreiben von Methoden.

Falconbyte unterstüzen

Betrieb und Pflege von Falconbyte brauchen viel Zeit und Geld. Um dir auch weiterhin hochwertigen Content anbieten zu können, kannst du uns sehr gerne mit einem kleinen "Trinkgeld" unterstützen.

Thema in Kurzform

  • Eine Methode darf keine geringere Zugriffsstufe haben als diejenige Methode, die sie überschreibt.

Tutorial

Rufen wir uns zunächst nochmal die Zugriffsmodifikatoren (hier mehr erfahren) ins Gedächtnis:

Zugriffstufe Klasse Paket Sub-Klasse Welt
public
protected
kein Modifier-Schlüsselwort (default)
private

Und jetzt sehen wir uns ein typisches Beispiel für das Überschreiben einer Methode an:

public class ToadA {

    protected int check(){
        return 1;
    }
}
public class ToadB extends ToadA{

    @Override
    protected int check() {
        return 2;
    }
}

Die Klasse ToadB erweitert ToadA und überschreibt die Methode check(). Dies funktioniert natürlich problemlos, da wir mit protected int check() in der überschriebenen Methode exakt die gleiche Methodendefinition verwenden wie in der Superklasse. Auch die Zugriffsmodifikatoren sind gleich (beide protected).

Ändern wir nun den Zugriffsmodifikator der Methode in ToadB von protected nach public:

public class ToadB extends ToadA{

    @Override
    public int check() {
        return 2;
    }
}

Obwohl die überschriebene Methode mit public jetzt eine andere Zugriffsstufe hat als in der Oberklasse (protected), ist auch dies problemlos compilierbar.

Halten wir bis hierhin fest: Es ist also durchaus möglich, dass in der Ursprungsmethode einer Superklasse und der überschriebenen Methode einer Unterklasse verschiedene Zugriffsstufen gesetzt sind.

Allerdings unterliegt dieser Annahme keine Beliebigkeit. Wenn wir nämlich die Zugriffsstufe in der überschriebenen Methode auf default (ohne Keyword) oder private setzen passiert Folgendes:

public class ToadB extends ToadA{

    @Override
    int check() { // ERROR!!
        return 2;
    }
}

Auch mit private hätten wir das gleiche Problem. Der Compiler gibt uns folgende Fehlermeldung:

  • check() in ToadB clashes with check() in ToadA; attempting to assign weaker access privileges.

Jetzt wissen wir genau, warum der Modifier public in ToadB funktioniert hat, die Zugriffsstufen default und private aber nicht. Es gibt nämlich eine klare Regel:

  • Eine Methode darf keine geringere Zugriffsstufe haben als diejenige Methode, die sie überschreibt.

Die Rangfolge der Zugriffsstufen sind: private -> default -> protected -> public

Wir hoffen auch für diesen "Spezialfall" etwas Licht ins Dunkel gebracht zu haben ☺️

Initializer

Eher selten aber praktisch!

toString() Methode

Lernen Sie hier, wie Sie die toString() Methode korrekt einsetzen

Objekte löschen

Wir wissen, wie wir Objekte erstellen können. Aber wie werden wir sie wieder los?

FALCONBYTE.NET

Handmade with 🖤️

© 2018-2022 Stefan E. Heller

Impressum | Datenschutz | Changelog

Falconbyte GitHub facebook programmieren lernen twitter programmieren lernen discord programmieren lernen