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 ☺️