In Java 8 wurde das Konzept der Standardmethoden eingeführt – das sind Methoden mit einer Implementierung, die innerhalb einer Schnittstelle deklariert sind. Sie ermöglichen das Hinzufügen neuer Methoden zu Schnittstellen, ohne die Kompatibilität mit bestehenden Implementierungen zu verletzen.
Syntax:
public interface MyInterface { default void printHello() { System.out.println("Hallo!"); } }
Eigenschaften und Feinheiten:
Object (z. B. equals, hashCode) nicht überschreiben.Was passiert, wenn eine Klasse zwei Schnittstellen mit identischer Standardmethode implementiert und diese Methode nicht überschreibt?
Antwort: Der Compiler gibt einen Fehler aus: "class... inherits unrelated defaults for ... from types ... and ...", und die Methode muss explizit in der Klasse implementiert werden.
Beispiel:
interface A { default void doSomething() { System.out.println("A"); } } interface B { default void doSomething() { System.out.println("B"); } } class C implements A, B {} // Compilerfehler!
Lösung:
class C implements A, B { @Override public void doSomething() { A.super.doSomething(); // oder B.super.doSomething() } }
Geschichte
In einem Teamprojekt zur Migration der API wurde eine Standardmethode zur gemeinsamen Schnittstelle hinzugefügt. Die alten Implementierungen der Schnittstelle überschrieben die neue Methode nicht, was zu unerwartetem Verhalten führte, da die Standardimplementierung anstelle der erwarteten Logik ausgeführt wurde. Infolgedessen bemerkten die Benutzer einen Funktionsverlust.
Geschichte
Bei der Erweiterung einer Bibliothek fügte ein Entwickler eine Standardmethode mit Geschäftslogik zur gemeinsamen Schnittstelle hinzu. Das anschließende Hinzufügen einer gleichnamigen Methode mit anderer Funktionalität in eine andere Schnittstelle führte zu einem Vererbungskonflikt, der das Kompilieren neuer Implementierungen verhinderte.
Geschichte
Ein Entwickler versuchte, eine Standardmethode mit dem Namen
hashCodein einer Schnittstelle zu verwenden und erwartete, dass dies das Überschreiben der Methode in den abgeleiteten Klassen beeinflussen würde, aber der Compiler erlaubte dies nicht. Dies führte zu langwierigen Untersuchungen der Fehlerursache und zur Überarbeitung der Struktur der Schnittstellen.