Detaillierte Einführung in die Standardmethode von Java8

Was ist die Standardmethode?

Nach der Veröffentlichung von Java 8 können der Schnittstelle neue Methoden hinzugefügt werden, die Schnittstelle kann jedoch weiterhin mit ihrer Implementierungsklasse kompatibel bleiben. Dies ist wichtig, da die von Ihnen entwickelte Bibliothek möglicherweise von mehreren Entwicklern häufig verwendet wird. Wenn vor Java 8 nach der Veröffentlichung einer Schnittstelle in einer Klassenbibliothek eine neue Methode zur Schnittstelle hinzugefügt wurde, bestand für Anwendungen, die diese Schnittstelle implementierten, die Gefahr eines Absturzes, wenn sie die neue Version der Schnittstelle verwenden.

Besteht bei Java 8 diese Gefahr nicht? Die Antwort ist nein.

Das Hinzufügen von Standardmethoden zu Schnittstellen kann dazu führen, dass bestimmte Implementierungsklassen nicht verfügbar sind.

Schauen wir uns zunächst die Details der Standardmethode an.

In Java 8 können Methoden in Schnittstellen implementiert werden (statische Methoden in Java 8 können auch in Schnittstellen implementiert werden, aber das ist ein anderes Thema). Die in der Schnittstelle implementierte Methode wird als Standardmethode bezeichnet und mit dem Schlüsselwort default als Modifikator identifiziert. Wenn eine Klasse eine Schnittstelle implementiert, kann sie Methoden implementieren, die bereits in der Schnittstelle implementiert sind, dies ist jedoch nicht erforderlich. Diese Klasse erbt die Standardmethode. Aus diesem Grund muss bei einer Änderung der Schnittstelle die Implementierungsklasse nicht geändert werden.

Was ist mit der Mehrfachvererbung?

Wenn eine Klasse mehr als eine (z. B. zwei) Schnittstellen implementiert und diese Schnittstellen dieselbe Standardmethode haben, werden die Dinge sehr kompliziert. Welche Standardmethode erbt die Klasse? Weder! In diesem Fall muss die Klasse selbst (direkt oder eine Klasse weiter oben im Vererbungsbaum) die Standardmethode implementieren.

Das Gleiche gilt, wenn eine Schnittstelle die Standardmethode implementiert und eine andere Schnittstelle die Standardmethode als abstrakt deklariert. Java 8 versucht, Mehrdeutigkeiten zu vermeiden und die Genauigkeit beizubehalten. Wenn eine Methode in mehreren Schnittstellen deklariert ist, wird keine der Standardimplementierungen geerbt und Sie erhalten einen Fehler bei der Kompilierung.

Wenn Sie Ihre Klasse jedoch kompiliert haben, treten beim Kompilieren keine Fehler auf. Zu diesem Zeitpunkt ist Java 8 inkonsistent. Es hat seine eigenen Gründe, und es gibt verschiedene Gründe. Ich möchte es hier nicht im Detail erklären oder ausführlich diskutieren (weil: die Version wurde veröffentlicht, die Diskussionszeit ist zu lang und diese Plattform hatte es noch nie). so eine Diskussion).

1. Angenommen, Sie haben zwei Schnittstellen und eine Implementierungsklasse.
2. Eine der Schnittstellen implementiert eine Standardmethode m().
3. Kompilieren Sie die Schnittstelle und die Implementierungsklasse zusammen.
4. Ändern Sie die Schnittstelle, die die m()-Methode nicht enthält, und deklarieren Sie die m()-Methode als abstrakt.
5. Kompilieren Sie die geänderte Schnittstelle separat neu.
6. Führen Sie die Implementierungsklasse aus.

Der Unterricht kann in der oben genannten Situation normal ablaufen. Eine Neukompilierung mit der geänderten Schnittstelle ist jedoch nicht möglich, die Kompilierung mit der alten Schnittstelle ist jedoch weiterhin möglich. Weiter

1. Ändern Sie die Schnittstelle mit der abstrakten Methode m() und erstellen Sie eine Standardimplementierung.
2. Kompilieren Sie die geänderte Schnittstelle
3. Führen Sie die Klasse aus: fehlgeschlagen.
Wenn zwei Schnittstellen eine Standardimplementierung für dieselbe Methode bereitstellen, kann diese Methode nicht aufgerufen werden, es sei denn, die Implementierungsklasse implementiert auch die Standardmethode (entweder direkt oder weiter oben in der Vererbungsbaumklasse übernimmt die Implementierung).

Diese Klasse ist jedoch kompatibel. Es kann über die neue Schnittstelle geladen und sogar ausgeführt werden, solange es keine Methoden aufruft, die in beiden Schnittstellen Standardimplementierungen haben.

Beispielcode:

Um das obige Beispiel zu demonstrieren, habe ich ein Testverzeichnis für C.java erstellt Darunter befinden sich außerdem drei Unterverzeichnisse, in denen I1.java und I2.java gespeichert werden. Das Testverzeichnis enthält den Quellcode C.java der Klasse C. Das Basisverzeichnis enthält die Version der Schnittstelle, die kompiliert und ausgeführt werden kann. I1 enthält die m()-Methode mit Standardimplementierung und I2 enthält keine Methoden.

Die Implementierungsklasse enthält die Hauptmethode, damit wir sie im Test ausführen können. Es prüft, ob Befehlszeilenparameter vorhanden sind, sodass wir problemlos Tests durchführen können, indem wir m() aufrufen und nicht m() aufrufen.

~/github/test$ cat C.java
public class C implements I1, I2 {
  public static void main(String[] args) {
    C c = new C();
    if(args.length == 0 ){
        c.m();
    }
  }
}
~/github/test$ cat base/I1.java
public interface I1 {
  default void m(){
    System.out.println("hello interface 1");
  }
}
~/github/test$ cat base/I2.java
public interface I2 {
}

Verwenden Sie zum Kompilieren und Ausführen die folgende Befehlszeile:

~/github/test$ javac -cp .:base C.java
~/github/test$ java -cp .:base C
hello interface 1

Das kompatible Verzeichnis enthält die I2-Schnittstelle mit der abstrakten Methode m() und die unveränderte I1-Schnittstelle.

~/github/test$ cat compatible/I2.java
public interface I2 {
  void m();
}

Dies kann nicht zum Kompilieren der Klasse C verwendet werden:

~/github/test$ javac -cp .:compatible C.java
C.java:1: error: C is not abstract and does not override abstract method m() in I2
public class C implements I1, I2 {
   ^
1 error

Die Fehlermeldung ist sehr präzise. Da wir die C.class in der vorherigen Kompilierung erhalten haben, erhalten wir beim Kompilieren der Schnittstellen im kompatiblen Verzeichnis immer noch zwei Schnittstellen, die die Implementierungsklasse ausführen können:

~/github/test$ javac compatible/I*.java
~/github/test$ java -cp .:compatible C
hello interface 1

Das dritte Verzeichnis wird aufgerufen falsch, die enthaltene I2-Schnittstelle definiert auch die m()-Methode:

~/github/test$ cat wrong/I2.java
public interface I2 {
  default void m(){
    System.out.println("hello interface 2");
  }
}

我们应该不厌其烦的编译它。尽管m()方法被定义了两次，但是，实现类仍然可以运行，只要它没有调用那个定义了多次的方法，但是，只要我们调用m()方法，立即就会失败。这是我们使用的命令行参数：

~/github/test$ javac wrong/*.java
~/github/test$ java -cp .:wrong C
Exception in thread "main" java.lang.IncompatibleClassChangeError: Conflicting
default methods: I1.m I2.m
    at C.m(C.java)
    at C.main(C.java:5)
~/github/test$ java -cp .:wrong C x
~/github/test$

结论

当你把给接口添加了default实现的类库移植到Java 8环境下的时候，一般不会有问题。至少Java8类库开发者给集合类添加default方法的时候就是这么想的。使用你类库的应用程序仍然依赖没有default方法的Java7的类库。当使用和修改多个不同的类库的时候，有很小的几率会发生冲突。如何才能避免呢？

像以前那样设计你的类库。可能依赖default方法的时候不要掉以轻心。万不得已不要使用。明智的选择方法名，避免和其它接口产生冲突。我们将会学习到Java编程中如何使用这个特性做开发。

更多Detaillierte Einführung in die Standardmethode von Java8相关文章请关注PHP中文网！