Les méthodes par défaut de Java 8 briseront-elles le code utilisateur ?

Au début, il semble que la méthode par défaut apporte de nombreuses nouvelles fonctionnalités au jeu d'instructions de la machine virtuelle Java. En fin de compte, les développeurs de bibliothèques pourront mettre à niveau l'API sans introduire de problèmes de compatibilité avec le code client. Avec les méthodes par défaut, toute classe qui implémente une interface de bibliothèque s'adapte automatiquement aux méthodes par défaut introduites par l'interface. Une fois que l'utilisateur met à jour la classe qu'il implémente, il est facile de remplacer la méthode par défaut d'origine par une méthode plus significative. Mieux encore, les utilisateurs peuvent appeler l'implémentation par défaut de l'interface et ajouter une logique métier lors du remplacement de la méthode.

Jusqu’ici, tout va bien. Cependant, l'ajout de méthodes par défaut lors de la création d'une interface peut rendre le code Java incompatible. Cela peut être facilement compris à partir de l’exemple ci-dessous. Supposons qu'une bibliothèque nécessite l'une de ses interfaces en entrée :

interface SimpleInput {   void foo();   void bar(); }  abstract class SimpleInputAdapter implements SimpleInput {   @Override   public void bar() {     // some default behavior ...   } }

Avant Java 8, similaire à la méthode ci-dessus consistant à combiner une interface et une classe d'adaptateur, il s'agissait d'un modèle de conception très courant dans le langage de programmation Java. Cet adaptateur est généralement fourni par le fournisseur de la bibliothèque pour épargner certaines opérations aux utilisateurs de la bibliothèque. Cependant, s’il est fourni sous la forme d’une interface, cela revient à autoriser l’héritage multiple.

Nous supposons en outre qu'un utilisateur utilise l'adaptateur suivant :

class MyInput extends SimpleInputAdapter {   @Override   public void foo() {     // do something ...   }   @Override   public void bar() {     super.bar();     // do something additionally ...   } }

Avec cette implémentation, nous pouvons enfin interagir avec la bibliothèque. Remarquez comment nous remplaçons la méthode bar et ajoutons des fonctionnalités supplémentaires à l'implémentation par défaut.

Que se passera-t-il si cette bibliothèque est portée sur Java 8 ? Premièrement, la bibliothèque dépréciera très probablement la classe d’adaptateur et utilisera la méthode par défaut pour fournir cette fonctionnalité. Finalement, l'interface ressemble à ceci :

interface SimpleInput {   void foo();   default void bar() {     // some default behavior   } }

Grâce à cette nouvelle interface, l'utilisateur peut mettre à jour son code pour utiliser les méthodes par défaut au lieu de la classe d'adaptateur d'origine. La conséquence ultime de l’utilisation d’une interface au lieu d’une classe d’adaptateur est que la classe peut étendre d’autres classes plutôt qu’un adaptateur spécifique. Pratiquons maintenant et transplantons la classe MyInput pour utiliser la méthode par défaut. Puisque nous pouvons désormais étendre d’autres classes, nous étendons une classe de base tierce. Nous n'avons pas besoin de nous soucier du rôle de cette classe de base ici, nous pouvons supposer que cela a un sens pour notre fonction.

class MyInput extends ThirdPartyBaseClass implements SimpleInput {   @Override   public void foo() {     // do something ...   }   @Override   public void bar() {     SimpleInput.super.bar();     // do something additionally ...   } }

Afin d'obtenir des fonctions similaires à la classe d'origine, nous utilisons la nouvelle syntaxe de Java 8 pour appeler la méthode par défaut de l'interface spécifiée. En même temps, déplacez une partie de la logique de nos méthodes vers la classe de base. À ce stade, vous me tapotez peut-être l'épaule et dites : c'est une très bonne refactorisation !

Nous avons utilisé cette bibliothèque avec beaucoup de succès. Cependant, les responsables doivent ajouter une autre interface pour fournir plus de fonctionnalités. Cette interface est remplacée par l'interface ComplexInput, qui hérite de l'interface SimpleInput et ajoute de nouvelles méthodes. Étant donné que les méthodes par défaut peuvent généralement être ajoutées en toute sécurité, les responsables ont remplacé la méthode par défaut de SimpleInput pour fournir une meilleure méthode par défaut. Après tout, c’est une chose courante avec les classes d’adaptateur.

interface ComplexInput extends SimpleInput {   void qux();   @Override   default void bar() {     SimpleInput.super.bar();     // so complex, we need to do more ...   } }

Les nouvelles fonctionnalités ont apporté de si bons résultats que les personnes qui maintiennent ThirdPartyBaseClass ont également décidé de s'appuyer sur cette bibliothèque. Pour effectuer ce travail, il implémente l'interface ComplexInput dans ThirdPartyLibrary.

Mais qu'est-ce que cela signifie pour la classe MyInput ? Afin d'implémenter implicitement l'interface ComplexInput, vous pouvez hériter de la classe ThirdPartyBaseClass, mais appeler la méthode par défaut de SimpleInput devient soudainement illégal. En conséquence, le code de l’utilisateur ne parvient pas à se compiler. Ce type d'appel est désormais interdit car Java considère qu'il est illégal d'appeler la méthode de la classe parent à partir d'une sous-classe non directe. Vous ne pouvez appeler cette méthode par défaut que dans ComplexInput, mais cela nécessite que vous implémentiez explicitement cette interface dans MyInput. Pour les utilisateurs de la bibliothèque, ce changement n’est pas attendu !

Ce qui est encore plus étrange, c'est que le runtime Java n'impose pas de telles restrictions. Le validateur de la JVM permet à une classe compilée d'appeler la méthode SimpleInput::foo, même si la classe implémente implicitement ComplexClass en héritant de la ThirdPartyBaseClass mise à jour. Cette restriction n'existe que dans le compilateur.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!