IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Du neuf sur les interfaces avec Java 8
Un tutoriel d'Olivier Croisier

Le , par Mickael Baron

6PARTAGES

5  0 
Olivier Croisier nous propose un tutoriel sur les nouveautés proposées par Java 8. Cet article s'intéresse plus particulièrement sur les nouvelles fonctionnalités introduites dans les interfaces Java.

Le lien pour le tutoriel : http://oliviercroisier.developpez.co...es-interfaces/

Profitez de cette discussion pour laisser des commentaires.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de professeur shadoko
Membre chevronné https://www.developpez.com
Le 14/02/2014 à 14:34
je me permet de signaler un erreur dans ce texte: l'emploi du mot "surcharge" au lieu de "specialisation" ou "redéfinition"
"surcharge" est le mot pour traduire "overloading" pas "overriding" et donc
1  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 20/02/2014 à 16:40
Citation Envoyé par Traroth2 Voir le message
Pour le coup, je me demande pourquoi ne pas avoir fait la même chose au niveau des classes, en fait. Je cherche une règle qui s'appliquererait plus difficilement à une classe qu'à une interface dans ce que tu expliques, mais je n'en vois pas...
Il n'y a pas besoin de cela au niveau des classes tu peux très bien rajouter une méthode dans une classe sans forcément "tout casser".

a++
1  0 
Avatar de thelvin
Modérateur https://www.developpez.com
Le 21/02/2014 à 0:37
Pour la factorisation, je ne vois toujours pas ce qui t'empêche de le faire avec des classes, maintenant comme depuis toujours.

Pour l'héritage multiple, le problème est toujours la question de l'héritage en diamant, et du fait que les classes définissent leur état interne. Une interface ne définit pas son état, et les méthodes par défaut ne peuvent qu'utiliser le contrat défini par les méthodes de l'interface, sans qu'il puisse y avoir question de l'effet sur les variables membres et lesquelles interviennent, puisque ça n'existe pas.
1  0 
Avatar de egann538
Membre actif https://www.developpez.com
Le 20/02/2014 à 10:18
Merci pour cet article. J'attendais depuis un moment ces méthodes par défaut dans les interfaces!
0  0 
Avatar de Traroth2
Membre émérite https://www.developpez.com
Le 20/02/2014 à 15:16
Pour le coup, je me demande pourquoi ne pas avoir fait la même chose au niveau des classes, en fait. Je cherche une règle qui s'appliquererait plus difficilement à une classe qu'à une interface dans ce que tu expliques, mais je n'en vois pas...

Merci pour cet article, en tout cas.
0  0 
Avatar de Traroth2
Membre émérite https://www.developpez.com
Le 21/02/2014 à 0:11
Citation Envoyé par adiGuba Voir le message
Il n'y a pas besoin de cela au niveau des classes tu peux très bien rajouter une méthode dans une classe sans forcément "tout casser".

a++
Oui, mais là, on parle de factorisation. Et d'héritage multiple, en fait.
0  0 
Avatar de la.lune
Membre chevronné https://www.developpez.com
Le 21/02/2014 à 3:06
Citation Envoyé par Traroth2 Voir le message
Oui, mais là, on parle de factorisation. Et d'héritage multiple, en fait.
Le fait qu'on manipule des méthodes de classe mère dans plusieurs classes filles différentes sans les redéfinir n'est ce pas de la factorisation ? Et quel est dans la réalité l'intérêt d'héritage multiple côté variables membres de l'objet? Ce sont les fonctionnalités qui sont sensé faire l'objet d'héritage multiple d'où le concept d'interface et je crois qu'avec les méthodes par défaut, on va pouvoir enfin faire cet héritage multiple de fonctionnalité sans avoir à implémenter ou réimplémenter les méthodes.
0  0 
Avatar de Traroth2
Membre émérite https://www.developpez.com
Le 21/02/2014 à 10:29
Citation Envoyé par thelvin Voir le message

Pour l'héritage multiple, le problème est toujours la question de l'héritage en diamant, et du fait que les classes définissent leur état interne. Une interface ne définit pas son état, et les méthodes par défaut ne peuvent qu'utiliser le contrat défini par les méthodes de l'interface, sans qu'il puisse y avoir question de l'effet sur les variables membres et lesquelles interviennent, puisque ça n'existe pas.
Pour les méthodes, rien n'empêcherait de résoudre le sujet exactement comme c'est fait avec les interfaces avec ce nouveau mécanisme de méthode par défaut. Mais effectivement, pour les attributs, ça pourrait devenir scabreux. Ca serait sûrement quand même faisable, mais en y réfléchissant, les méthodes par défaut dans les interfaces permettent de s'en passer, en fait.
0  0 
Avatar de thelvin
Modérateur https://www.developpez.com
Le 21/02/2014 à 10:38
Faisable, oui. Un appel de rassemblement des bugs, oui aussi. Et c'est en général contre la volonté de Java.
0  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 21/02/2014 à 11:05
Citation Envoyé par thelvin Voir le message
Faisable, oui. Un appel de rassemblement des bugs, oui aussi. Et c'est en général contre la volonté de Java.
+1

L'héritage multiple apporte plus de problème qu'il n'en résout.
De plus cela va à l'encontre de la philosophie de Java où les méthodes d'instances sont "virtuelles" par défaut (c'est à dire qu'elle peuvent être redéfinies dans une sous-classes).

L'héritage multiple apporterait tellement de problème de ce coté là qu'on finirait par déclarer toutes nos méthodes final pour éviter les soucis... mais en "pourrissant" l'API.

Surtout que les méthodes par défaut permettront de prendre la majorité des avantages de l'héritage multiple... sans les principaux problèmes !

Sinon petite remarque : comme pour une classe, l'ajout d'une méthode par défaut dans une interface n'est pas forcément sans risque, et cela peut des incompatibilités dans certains cas de conflits de noms (incompatibilités des sources la plupart du temps).

a++
0  0