Wann verwenden: Java 8+ Interface-Standardmethode vs. abstrakte Methode

Question

Java 8 ermöglicht die Standardimplementierung von Methoden in Interfaces, die als Default Methods bezeichnet werden.

Ich bin verwirrt darüber, wann ich diese Art von Interface-Standardmethode verwenden sollte, anstelle einer abstrakten Klasse (mit abstrakten Methoden).

Wann sollte ein Interface mit Standardmethoden verwendet werden und wann sollte eine abstrakte Klasse (mit abstrakten Methoden) verwendet werden? Sind die abstrakten Klassen in diesem Szenario immer noch nützlich?

Answer 1

Es steckt viel mehr hinter abstrakten Klassen als Standard-Methodenimplementierungen (wie privater Zustand), aber seit Java 8 sollte man sich immer für die Verteidiger (auch bekannt als default) Methode im Interface entscheiden, wenn man die Wahl hat.

Die Einschränkung der Standardmethode besteht darin, dass sie nur in Form von Aufrufen anderer Interface-Methoden implementiert werden kann, ohne Bezug auf den Zustand einer bestimmten Implementierung. Das Hauptanwendungsbeispiel sind also Methoden auf höherer Ebene und Komfortfunktionen.

Das Gute an diesem neuen Feature ist, dass man nun, anstatt eine abstrakte Klasse für die Komfortmethoden verwenden zu müssen, was den Implementierer auf eine einzige Vererbung beschränkt, ein wirklich sauberes Design nur mit dem Interface haben kann und ein Minimum an Implementierungsaufwand vom Programmierer gefordert wird.

Die ursprüngliche Motivation für die Einführung von default Methoden in Java 8 war der Wunsch, die Schnittstellen des Collections-Frameworks um lambda-orientierte Methoden zu erweitern, ohne vorhandene Implementierungen zu beeinträchtigen. Obwohl dies eher für die Autoren von öffentlichen Bibliotheken relevant ist, könnten Sie diese Funktion auch in Ihrem Projekt nützlich finden. Sie haben einen zentralen Ort, um neue Komfortfunktionen hinzuzufügen, und müssen sich nicht auf das Aussehen des Rests der Typenhierarchie verlassen.

Answer 2

Es gibt ein paar technische Unterschiede. Abstrakte Klassen können im Vergleich zu Java 8 Schnittstellen immer noch mehr leisten:

1. Abstrakte Klassen können einen Konstruktor haben.
2. Abstrakte Klassen sind strukturierter und können einen Zustand halten.

Konzeptionell besteht der Hauptzweck von Verteidigungsmethoden darin, die Abwärtskompatibilität nach der Einführung neuer Funktionen (wie Lambda-Funktionen) in Java 8 sicherzustellen.

Answer 3

Dies wird in diesem Artikel beschrieben. Denken Sie über forEach von Collections nach.

List list = …
list.forEach(…);

Das forEach wird weder von java.util.List noch vom java.util.Collection Interface deklariert. Eine offensichtliche Lösung wäre, einfach die neue Methode zum bestehenden Interface hinzuzufügen und die Implementierung dort bereitzustellen, wo es im JDK erforderlich ist. Sobald jedoch veröffentlicht, ist es unmöglich, Methoden zu einem Interface hinzuzufügen, ohne die bestehende Implementierung zu beeinträchtigen.

Der Vorteil, den Standardmethoden bieten, ist, dass jetzt eine neue Standardmethode zum Interface hinzugefügt werden kann, ohne die Implementierungen zu beeinträchtigen.

Answer 4

Wie in diesem Artikel beschrieben,

Abstrakte Klassen gegenüber Schnittstellen in Java 8

Nach der Einführung der Standardmethode scheint es, dass Schnittstellen und abstrakte Klassen gleich sind. Sie sind jedoch immer noch unterschiedliche Konzepte in Java 8.

Abstrakte Klassen können Konstruktoren definieren. Sie sind strukturierter und können einen Zustand mit sich bringen. Im Gegensatz dazu können Standardmethoden nur in Bezug auf das Aufrufen anderer Schnittstellenmethoden implementiert werden, ohne auf den Zustand einer bestimmten Implementierung Bezug zu nehmen. Daher werden beide für unterschiedliche Zwecke verwendet, und die Wahl zwischen beiden hängt wirklich vom Szenario-Kontext ab.

Answer 5

Immer wenn wir die Wahl zwischen abstrakter Klasse und Interface haben, sollten wir immer (fast immer) standardmäßige (auch als Verteidiger oder virtuelle Erweiterungen bekannte) Methoden bevorzugen.

1. Standardmethoden haben dem klassischen Muster von Schnittstelle und einer Begleitklasse, die die meisten oder alle Methoden in dieser Schnittstelle implementiert, ein Ende gesetzt. Ein Beispiel ist Collection und AbstractCollection. Jetzt sollten wir die Methoden in der Schnittstelle selbst implementieren, um eine Standardfunktionalität bereitzustellen. Die Klassen, die die Schnittstelle implementieren, haben die Wahl, die Methoden zu überschreiben oder die standardmäßige Implementierung zu erben.

2. Ein weiterer wichtiger Verwendungszweck von Standardmethoden ist die Schnittstellenevolution. Angenommen, ich hätte eine Klasse Ball wie folgt:

   public class Ball implements Collection { ... }

Jetzt in Java 8 wurde ein neues Merkmal Streams eingeführt. Wir können einen Stream erhalten, indem wir die zum Interface hinzugefügte Methode stream verwenden. Wenn stream keine Standardmethode wäre, würden alle Implementierungen für das Collection-Interface kaputt gehen, da sie diese neue Methode nicht implementieren würden. Das Hinzufügen einer nicht standardmäßigen Methode zu einer Schnittstelle ist nicht quellkompatibel.

Aber angenommen, wir kompilieren die Klasse nicht neu und verwenden eine alte Jar-Datei, die diese Klasse Ball enthält. Die Klasse wird ohne diese fehlende Methode ordnungsgemäß geladen, Instanzen können erstellt werden und es scheint alles zu funktionieren. ABER wenn das Programm die Methode stream auf der Instanz von Ball aufruft, erhalten wir einen AbstractMethodError. Das Festlegen der Methode als Standard löst also beide Probleme.

Java 9 hat sogar private Methoden in der Schnittstelle, die verwendet werden können, um den gemeinsamen Code zu kapseln, der in den Schnittstellenmethoden verwendet wurde, die eine Standardimplementierung bereitgestellt haben.