Discussion :

[professeur shadoko]

Bonjour,

Dans la découverte de Java 8, je constate que dans une interface il est impossible de définir une méthode qui soit à la fois default et final.

Pourtant, j'aurais aimé pouvoir définir une méthode qui ne soit pas redéfinissable mais injectée dans toutes les classes qui implémentent l'interface.
Apparemment il y a contradiction...

Je ne vois pas très clairement le raisonnement (j'ai juste quelques soupçons).

Quelqu'un saurait-il m'expliquer cela ?

Merci d'avance.

[benratti]

Le principe des méthodes par défaut dans les interfaces, c'est de permettre de fournir une implémentation pour les nouvelles méthodes lorsque l'on fait évoluer une interface. Mais ça reste une interface, dont la classe qui l'implémente doit pouvoir fournir sa propre implémentation. C'est en tout cas dans ce but, me semble t il, que les implémentations par défaut ont été mise en place...

Ce qui explique le fait que les mots clés default et final ne serait pas compatible.

[professeur shadoko]

Ce qui explique le fait que les mots clés default et final ne serait pas compatible.

euH? pas convaincu ... un autre argument ?

[thelvin]

Autant je comprends le besoin d'une méthode qui ne soit pas redéfinissable, mais fournie avec une interface, comme on l'aurait fait avant dans une classe utilitaire séparée,
Autant quand on voit default l'existence du même truc "pas par défaut" tombe un peu sous le sens, quand même -_-°.

Je dirais que permettre ça remettrait sur la table le délicat problème de l'héritage multiple, que faire si deux interfaces proposent la même méthode, et qu'aucune des deux n'autorise sa redéfinition ?
(En fait concrètement, c'est quoi exactement le cheminement, pour vouloir implémenter une méthode dans une interface, mais ne surtout pas vouloir qu'elle soit ré-implémentée par autre chose ? Avec des classes je comprends, 'faut pas toucher aux invariants. Mais avec une interface...)

[professeur shadoko]

ça se tient.
Mais mon interrogation venait de l'histoire de mon code:
- j'ai des composants complexes qui ont une méthode final (et elle doit l'être!)
- pour ceux qui voulaient des composants analogues avec moins de fonctionalités j'avais une interface à implanter
- avec java 8 je fais "remonter" pas mal de méthode du composant complexe à l'interface (c'est possible)
mais voilà: la méthode 'final' a tout ce qu'il faut pour être intégrée à l'interface .... sauf qu'elle est final !
dont glissement sémantique: les méthodes default de l'interface étaient là pour implanter des comportements pre-cablés dans les classes ...
la frontière entre le sens de l'interface et l'implantation automatiques étant ténues .... j'ai un peu tiqué...

[Gugelhupf]

A la base, toutes les méthodes d'une interfaces existent pour qu'on puisse les redéfinir, c'est la définition même que donnent les enseignants : "Une interface décrit une capacité, ce qui se traduit par des méthodes à implémenter".

Avec Java 8 tu peux certes avoir des méthodes par défaut que tu pourras redéfinir, des méthodes static que tu ne pourras pas redéfinir, mais tout ça c'est du bonus. Sinon tu peux toujours utiliser une classe abstraite pour réaliser ton besoin.

[professeur shadoko]

oui certes ... encore une fois j'ai attribué indûment aux nouvelles interfaces des propriétés des "traits"
en Groovy par exemple une méthode de trait peut-être final
les effets en Groovy n'en sont toutefois pas simples à prévoir.
la lecture des specs java n'est pas claire, claire sur ce double aspect contrat d'interface/code par défaut.
(le rejet de final est dans la description syntaxique uniquement)