Quand l'utiliser : Méthode par défaut de l'interface Java 8+, vs. méthode abstraite

Question

Java 8 permet l'implémentation par défaut de méthodes dans des interfaces appelées Méthodes par défaut .

Je suis confus entre le moment où j'utiliserais ce genre de interface default method au lieu d'un abstract class (avec abstract method(s) ).

Alors, quand faut-il utiliser une interface avec des méthodes par défaut et quand faut-il utiliser une classe abstraite (avec une ou plusieurs méthodes abstraites) ? Les classes abstraites sont-elles encore utiles dans ce scénario ?

Answer 1

Les classes abstraites comportent bien plus que des implémentations de méthodes par défaut (comme l'état privé), mais à partir de Java 8, lorsque vous avez le choix entre les deux, vous devez opter pour le défenseur (alias. default ) de l'interface.

La contrainte sur la méthode par défaut est qu'elle ne peut être implémentée qu'en termes d'appels à d'autres méthodes d'interface, sans référence à l'état d'une implémentation particulière. Le principal cas d'utilisation est donc celui des méthodes de niveau supérieur et de commodité.

L'avantage de cette nouvelle fonctionnalité est que, alors qu'auparavant vous étiez obligé d'utiliser une classe abstraite pour les méthodes de commodité, contraignant ainsi l'implémenteur à l'héritage unique, vous pouvez maintenant avoir une conception vraiment propre avec juste l'interface et un minimum d'effort d'implémentation imposé au programmeur.

La motivation initiale de l'introduction de la default Le désir d'étendre les interfaces du Collections Framework avec des méthodes orientées lambda sans rompre les implémentations existantes a été à l'origine de l'introduction des méthodes lambda dans Java 8. Bien que cela soit plus pertinent pour les auteurs de bibliothèques publiques, vous pouvez trouver la même fonctionnalité utile dans votre projet également. Vous disposez d'un endroit centralisé où ajouter de nouvelles commodités et vous ne devez pas dépendre de l'aspect du reste de la hiérarchie des types.

Answer 2

Il existe quelques différences techniques. Les classes abstraites peuvent toujours faire plus par rapport aux interfaces de Java 8 :

1. Une classe abstraite peut avoir un constructeur.
2. Les classes abstraites sont plus structurées et peuvent contenir un état.

D'un point de vue conceptuel, le principal objectif des méthodes défenderesses est la rétrocompatibilité après l'introduction de nouvelles fonctionnalités (comme les fonctions lambda) dans Java 8.

Answer 3

C'est ce qui est décrit dans ce article . Pensez à forEach des collections.

List<?> list = …
list.forEach(…);

Le forEach n'est pas déclaré par java.util.List ni le java.util.Collection encore une interface. Une solution évidente serait de d'ajouter la nouvelle méthode à l'interface existante et de fournir l'implémentation de la méthode. l'implémentation dans le JDK. Cependant, une fois publiée, il est il est impossible d'ajouter des méthodes à une interface sans casser la implémentation existante.

L'avantage des méthodes par défaut est qu'il est maintenant possible de d'ajouter une nouvelle méthode par défaut à l'interface sans pour autant casser les implémentations.

Answer 4

Comme décrit dans ce article,

Classes abstraites et interfaces en Java 8

Après avoir introduit la méthode par défaut, il semble que les interfaces et les classes abstraites soient les mêmes. classes abstraites sont identiques. Cependant, elles sont toujours un concept différent dans Java 8.

Une classe abstraite peut définir un constructeur. Elles sont plus structurées et peuvent avoir un état qui leur est associé. Alors qu'à l'inverse, la méthode par défaut ne peut être implémentée qu'en termes d'invocation d'autres méthodes d'interface, sans référence à une implémentation particulière de la méthode. méthodes d'interface, sans référence à l'état d'une implémentation particulière. d'une implémentation particulière. Par conséquent, les deux sont utilisés à des fins différentes et le choix entre les deux dépend réellement du contexte du scénario.

Answer 5

Lorsque nous avons le choix entre une classe abstraite et une interface, nous devrions toujours (presque) préférer les méthodes par défaut (également connues sous le nom d'extensions défensives ou virtuelles).

1. Les méthodes par défaut ont mis fin au modèle classique d'interface et de classe d'accompagnement qui implémente la plupart ou toutes les méthodes de cette interface. Un exemple est Collection and AbstractCollection . Maintenant, nous devons implémenter les méthodes dans l'interface elle-même pour fournir une fonctionnalité par défaut. Les classes qui implémentent l'interface ont le choix de surcharger les méthodes ou d'hériter de l'implémentation par défaut.

2. Une autre utilisation importante des méthodes par défaut est interface evolution . Supposons que j'aie une classe Ball comme :

   public class Ball implements Collection { ... }

Maintenant, dans Java 8, une nouvelle fonctionnalité de flux est introduite. Nous pouvons obtenir un flux en utilisant stream ajoutée à l'interface. Si stream n'étaient pas une méthode par défaut, toutes les implémentations pour les Collection aurait été cassée car elle n'aurait pas mis en œuvre cette nouvelle méthode. L'ajout d'une méthode non par défaut à une interface n'est pas source-compatible .

Mais supposons que nous ne recompilions pas la classe et que nous utilisions un ancien fichier jar qui contient cette classe Ball . La classe se charge bien sans cette méthode manquante, des instances peuvent être créées et il semble que tout fonctionne bien. MAIS si le programme invoque stream sur une instance de Ball nous obtiendrons AbstractMethodError . La méthode par défaut a donc résolu les deux problèmes.

Java 9 a même des méthodes privées dans l'interface qui peuvent être utilisées pour encapsuler la logique de code commune qui était utilisée dans les méthodes de l'interface qui fournissaient une implémentation par défaut.