Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
[Java 8] default method: pas de final possible
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.
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.
euH?Envoyé par benratti
pas convaincu ... un autre argument ?
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...)
ç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é...
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.
N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java
Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ?Contacter Gokan EKINCI
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)
Salut,
Il y a une réponse assez complète de Brian Goetz ici : http://stackoverflow.com/questions/2...76994#23476994
Il rappelle en particulier que les méthodes par défaut n'ont pas pour objectif de transformer les interfaces en Traits, mais seulement de permettre l'évolution des interfaces.
a++
j'étais justement en train de lire cette discussion: le point de Brian Goetz est convaincant.
un des arguments aussi qu'on a tendance à oublier dans les discussions: que se passe t'il en cas d'évolution d'un code déjà publié!
Perso je suis de temps en temps certaines discussion sur les mailings list de java.
Ils y a vraiment beaucoup de choses qui sont prise en considération, notamment sur les effets indésirables que cela peut entrainer, ou sur les limitations futures que cela pourraient entrainer.
Au final on peut avoir l'impression que le langage évolue peu ou lentement, mais chaque décision me semble pensée et réfléchie.
a++
Pour le coup Java est un peu coupable d'avoir permis d'implémenter directement des méthodes dans l'interface. Résultat les interfaces sont persques des trait mais pas totalement. Les première idées avaient le mértie de ne pas laisser de doute sur le but des methodes par défaut.
De quelles premières idées parles-tu ?
Sinon oui les default-methods ne sont pas des Traits, même s'ils peuvent être utilisé dans des objectifs similaires.
La principale différence vient du fait que même s'il y a du code, il n'y a toujours pas d'état dans les interfaces.
Toutes les méthodes par défaut doivent se baser uniquement sur le contrat de l'interface dans laquelle elles sont définies...
a++
Si je me souviens bien, au début, plutot que de définir les implémentations des méthodes par défaut à l'interieur de l'interface, il était question de faire pointer ces méthodes sur des méthode statiques.
Même si au final ca ne changeait pas grand chose du point de vue des possibilités techniques, ça réduisait ce risque de confusion.
Ah oui en effet mais c'est avant tout une question de syntaxe. Cela n'aurait rien changé d'un point de vue possibilités.
C'est juste qu'il aurait fallut écrire une classes d'utilitaires static en plus, et en simulant le this en premier paramètre...
Bref cela aurait juste été un peu plus lourd à écrire...
a++
En effet techniquement, ça ne réduit pas les possibilités, mais je pense que le fait de séparer l'implémentation de l'interface aurait certainement aidé a comprendre que le but n'est pas de transformer les interfaces en Trait.
Mais cela ne l'aurait pas empêché pour autant. Donc autant privilégié une syntaxe claire et précise pour ceux qui l'utiliseront correctement
Exemple avec les extension-methode de C# : http://newtocode.wordpress.com/2014/...aits-in-c-3-0/
J'ai vu passer d'autre article qui indique comment faire des "Traits" en Java, en gérant un état via des Map en static ! (vas-y la méchante fuite mémoire - sans parler du fait que ce n'est pas thread-safe du tout).
Celui-là par exemple : http://kerflyn.wordpress.com/2012/07...u-have-mixins/
Bref y'aura toujours des mauvaises pratiques, quelque soit le langage
a++
C'est exactement ce que je dit le coté monobloc de la syntaxe a poussé les gens a croire que l'on avait un vrai système de Trait/Mixin, alors que le but a la base était seulement de permettre d'étendre les interface sans casser la compatibilité antérieure.
Je ne dis pas qu'il n'y aurait pas eu de grands malade qui auraient préconisé la même chose que ton arcticle en recourant en plus a des méthodes statiques, mais franchement, avec la complexité supplémentaire, je ne pense pas que grand monde aurait considéré ça autrement qu'un hack marant mais trop sale a utiliser.
Sérieusement ? Une classe aussi c'est monobloc, et les interfaces l'étaient déjà avant les default methods et les static methods.
Et elles passaient pas pour des traits ou mixins, mais maintenant si ?
Il y a vraiment plein de gens qui ont halluciné ça ?
Les méthodes par défaut peuvent être utilisées pour faire une sorte d'héritage multiple, et certains font le raccourci vers les Traits...
C'est complètement erroné et ce n'est pas du tout l'objectif des méthodes par défaut, mais le rapprochement est souvent fait...
a++
par contre dans l'article il y a une référence au "virtual field pattern": je l'utilisais déjà pas mal mais là les méthodes par défaut d'interface ont complétement chamboulé certains codes en me permettant un transfert massifCelui-là par exemple : http://kerflyn.wordpress.com/2012/07...u-have-mixins/
Bref y'aura toujours des mauvaises pratiques, quelque soit le langage
de fonctionnalités d'une classe vers une interface (les seules méthodes abstraites de l'interface font référence au get/set du champ virtuel qui apporte les fonctionnalités)
Répondre avec citation
Partager