Quelle est l’implémentation “par défaut” de la méthode définie dans une interface?

Dans l’interface de collection, j’ai trouvé une méthode nommée removeIf() qui contient son implémentation.

 default boolean removeIf(Predicate filter) { Objects.requireNonNull(filter); boolean removed = false; final Iterator each = iterator(); while (each.hasNext()) { if (filter.test(each.next())) { each.remove(); removed = true; } } return removed; } 

Je veux savoir s’il existe un moyen de définir le corps de la méthode dans une interface?
Quel est le mot-clé default et comment fonctionne-t-il?

Java 8 introduit la nouvelle fonctionnalité «Méthode par défaut» (Defender methods), qui permet aux développeurs d’append de nouvelles méthodes aux interfaces sans casser l’implémentation existante de ces interfaces. Il offre la flexibilité nécessaire pour permettre une implémentation de l’interface qui utilisera par défaut une situation où une classe concrète ne parvient pas à fournir une implémentation pour cette méthode.

 public interface A { default void foo(){ System.out.println("Calling A.foo()"); } } public class ClassAB implements A { } 

Il y a une question que les gens se posent souvent sur les méthodes par défaut lorsqu’ils entendent parler de la nouvelle fonctionnalité pour la première fois:

Que se passe-t-il si la classe implémente deux interfaces et que ces deux interfaces définissent une méthode par défaut avec la même signature?

Exemple pour illustrer cette situation:

 public interface A { default void foo(){ System.out.println("Calling A.foo()"); } } public interface B { default void foo(){ System.out.println("Calling B.foo()"); } } public class ClassAB implements A, B { } 

Ce code ne parvient pas à comstackr avec le résultat suivant:

 java: class Clazz inherits unrelated defaults for foo() from types A and B 

Pour corriger cela, dans Clazz, nous devons le résoudre manuellement en remplaçant la méthode en conflit:

 public class Clazz implements A, B { public void foo(){} } 

Mais que faire si nous souhaitons appeler l’implémentation par défaut de la méthode foo () depuis l’interface A au lieu d’implémenter la notre.

Il est possible de se référer à A # foo () comme suit:

 public class Clazz implements A, B { public void foo(){ A.super.foo(); } } 

Ces méthodes sont appelées méthodes par défaut. La méthode par défaut ou la méthode Defender est l’une des nouvelles fonctionnalités de Java 8.

Ils seront utilisés pour permettre à une méthode d’interface de fournir une implémentation utilisée par défaut si une classe concrète ne fournit pas d’implémentation pour cette méthode.

Donc, si vous avez une interface, avec une méthode par défaut:

 public interface Hello { default void sayHello() { System.out.println("Hello"); } } 

La classe suivante est parfaitement valide:

 public class HelloImpl implements Hello { } 

Si vous créez une instance de HelloImpl :

 Hello hello = new HelloImpl(); hello.sayHello(); // This will invoke the default method in interface 

Liens utiles:

  • Didacticiel Oracle mis à jour
  • Tout sur Java 8
  • Méthodes Defender

J’ai fait un peu de recherche et j’ai trouvé ce qui suit. J’espère que cela t’aides.

Problème existant

Les méthodes d’interface normales sont déclarées comme abstraites et doivent être définies dans la classe qui implémente l’interface. Cela «impose» à l’implémentateur de classe la responsabilité de mettre en œuvre toutes les méthodes déclarées. Plus important encore, cela signifie également que l’extension d’une interface n’est pas possible après la publication. Sinon, tous les implémenteurs devraient adapter leur implémentation, en brisant la source en amont et la compatibilité binary.

Solution adoptée dans Java 8

Pour faire face à ces problèmes, l’une des nouvelles fonctionnalités de JDK 8 est la possibilité d’étendre les interfaces existantes avec les méthodes par défaut. Les méthodes par défaut sont non seulement déclarées, mais également définies dans l’interface.

Points importants à noter

  1. Les implémenteurs peuvent choisir de ne pas implémenter les méthodes par défaut dans la classe d’implémentation.
  2. Les implémenteurs peuvent toujours remplacer les méthodes par défaut, comme les méthodes de classe non finales régulières peuvent être remplacées dans les sous-classes.
  3. Les classes abstraites peuvent même (re) déclarer les méthodes par défaut comme abstraites, obligeant les sous-classes à réimplémenter la méthode (parfois appelée «réabstraction»).