Discussion :

[iliasvow]

Bonjour
j'ai definit une interface Materiel avec deux variables et une méthode afficher (),et aprés j'ai définit Ordinateur comme class qui hérite de Matériel avec un constructeur paramétré qui affecte les paramétres aux deux variables definis dans l'interface et avec la méthode afficher() redéfini du coup ça compile pas,j'ai toujours le message de
public String marque; ( = expected !!)

[thelvin]

Ça veut rien dire ce que tu racontes, la prochaine fois montre ton code.

Mais je te le dis au cas où : dans une interface les variables membres sont forcément static final, que tu le dises ou pas. Il faut donc obligatoirement leur donner une valeur. Ce sont donc des "constantes", on ne peut pas s'en servir comme état interne d'objets.
Tes variables d'état doivent être dans des classes, pas dans des interfaces.

[clubist]

Bonjour,

Les attributs dans une interface en JAVA sont obligatoirement public static final implicitement ( même si tu mets pas ça explicitement).

Alors toute classe qui implémente cette interface ou toute interface qui hérite cette interface ne peut pas modifier sa valeur, en plus la valeur d'attribut interface doit être initialisée lors de sa déclaration.

Merci

[tchize_]

Bonjour
j'ai definit une interface Materiel avec deux variables et une méthode afficher ()

Une interface ne définit pas de variable, juste des méthodes et des constantes.

[thelvin]

Une interface ne définit pas de variable, juste des méthodes et des constantes.

Précision linguistique : ce ne sont pas des constantes au sens Java. Ce sont juste des variables public static final. On dit "constantes" parce que tout le monde peut les voir et qu'on ne peut pas leur assigner de nouvelle valeur, donc la variable reste la même. Une constante, en Java, ça veut dire autre chose.

[tchize_]

oracle appelle bien ça des constantes:

http://docs.oracle.com/javase/6/docs...nt-values.html

[thelvin]

Bonne remarque, autant pour moi. Je faisais référence à ce que Java appelle des variables constantes. Alors que là la javadoc appelle ça des champs constants. Finalement la nomenclature est plus tirée par les cheveux que je le pensais -_-°.

[yotta]

En fait, je ne suis pas d'accord avec vous Thelvin. Ce que iliasvow écrit veut dire beaucoup de chose...
En fait, si on lit bien, ce qu'il écrit nous permet de remarquer qu'il ne fait pas la différence entre une classe et une interface.
En effet, iliasvow écrit :

j'ai definit une interface Materiel...

Puis, plus loin, il écrit :

j'ai définit Ordinateur comme class qui hérite de Matériel...

Depuis quand une classe hérite-t-elle d'une interface ?
A ce constat s'ajoute le fait que nous sommes dans la rubrique "Débutant", donc je conclus :
iliasvow n'a pas compris la différence entre Classe et Interface.
Donc, les compétences de ce monsieur ne lui auront certainement pas permis de comprendre quoi que ce soit de vos réponse...
Je penses que le plus sage des conseils est de l'inviter à parcourir les premiers tutoriaux Java, plus précisément "Java, et la programmation orienté objet".
Bref, iliasvow, je vous invites à consulter la documentation suivante :
http://www.developpez.com/download/introobj.pdf

[thelvin]

Mon conseil c'était de montrer le code. Le reste, comme je l'ai dit clairement, je le disais au cas où.

On est pas tout à fait sûr qu'il ne sait pas ce que c'est des classes ou des interfaces. Personne ne sait utiliser le verbe "hériter" correctement de toute façon. Soit dit en passant, une classe hérite d'une interface depuis qu'une interface possède des trucs dont elle puisse hériter. Comme, par exemple, des variables statiques. Ou des classes statiques. Ou depuis Java 8, les méthodes statiques et les méthodes par défaut. Tout ça, les classes qui implémentent une interface, l'héritent de cette interface.

[adiGuba]

Salut,

Bonne remarque, autant pour moi. Je faisais référence à ce que Java appelle des variables constantes. Alors que là la javadoc appelle ça des champs constants. Finalement la nomenclature est plus tirée par les cheveux que je le pensais -_-°.

Cela peut tout à fait être les deux ! Un champs static final peut être à la fois un attribut static final et une constante.

Une constante est une variable déclarée final, initialisé en ligne, et dont la valeur peut-être déterminé dès la compilation, ce qui limite son utilisation aux types primitifs et aux String.

L'intérêt d'une constante c'est que le compilateur javac remplacera l'appel à l'attribut par sa valeur partout où il la trouvera. Il pourra même effectuer certains calcul à l'avance...

On est pas tout à fait sûr qu'il ne sait pas ce que c'est des classes ou des interfaces. Personne ne sait utiliser le verbe "hériter" correctement de toute façon. Soit dit en passant, une classe hérite d'une interface depuis qu'une interface possède des trucs dont elle puisse hériter. Comme, par exemple, des variables statiques. Ou des classes statiques.

Attention il est un peu faux de dire que les éléments static sont hérité !
En effet les éléments static (attributs, méthodes ou classes) ne sont pas lié à l'instance de la classe, et n'ont donc rien à voir avec l'héritage (il n'est pas possible de redéfinir ces éléments par exemple)
En fait lorsqu'on hérite d'une classe ou implémente une interface, on gagne juste une visibilité sur les éléments static qui y sont définie.

Le langage permet bien d'appeler directement une méthode ou un attribut statique définie dans une classe parente (sans le préfixer du nom de cette classe), mais c'est juste une facilité.
C'est le compilateur qui résolve implicitement la méthode static à exécuter.

Ou depuis Java 8, les méthodes statiques et les méthodes par défaut. Tout ça, les classes qui implémentent une interface, l'héritent de cette interface.

A noter que contrairement aux méthodes statiques définies dans une classes parentes, on ne peut pas appeler directement une méthode statique définie dans une interface que l'on implémente.

Pour appeler une méthode static définie dans une interface, il faut soit la préfixer par le nom de l'interface, soit utiliser un import static.


a++

[thelvin]

Cela peut tout à fait être les deux ! Un champs static final peut être à la fois un attribut static final et une constante.

Une constante est une variable déclarée final, initialisé en ligne, et dont la valeur peut-être déterminé dès la compilation, ce qui limite son utilisation aux types primitifs et aux String.

L'intérêt d'une constante c'est que le compilateur javac remplacera l'appel à l'attribut par sa valeur partout où il la trouvera. Il pourra même effectuer certains calcul à l'avance...

Ouaip, je me suis trompé deux fois de suite. Le listing des "champs constants" ne liste effectivement que des variables constantes. C'est à dire final et qui sont évaluées par le compilateur, donc remplacées par leur valeur par le compilateur.
Ce que je voulais dire à ce moment-là, c'est qu'un champ static final auquel on n'assigne pas une expression constante, n'est pas une constante. Et personne a jamais dit que les variables dont on parle sont pas des Date ou des Integer. Donc c'est pas forcément des constantes.

En fait lorsqu'on hérite d'une classe ou implémente une interface, on gagne juste une visibilité sur les éléments static qui y sont définie.

L'héritage, ça a jamais été autre chose que cette visibilité.

Forcément, dans le cas de variables d'instance, ça a une implication qui va bien au-delà de l'intérêt de la seule visibilité : si on peut voir cette variable dont on hérite (ou même, si on a visibilité d'une méthode ou de quelque chose qui utilise une variable , même si on peut pas voir cette variable,) c'est qu'elle existe ! Autrement dit les variables d'instance qui existent dans les types parents, sont créées pour les instances des enfants, et il est nécessaire de définir pour le langage comment cela marche au juste.
Il n'empêche, une classe hérite de quelque chose, quand elle a visibilité sur ce quelque chose.

À noter que les variables privées ne sont pas héritées, mais existent bel et bien. Le mécanisme dont on a parlé plus haut, bien que fortement corrélé à l'intérêt de l'héritage, est en fait parfaitement distinct.

Pour appeler une méthode static définie dans une interface, il faut soit la préfixer par le nom de l'interface, soit utiliser un import static.

D'accord, ça je n'avais pas remarqué. Elles ne sont donc pas héritées.

[adiGuba]

L'héritage, ça a jamais été autre chose que cette visibilité.

Pour les méthodes il y a aussi la notion de redéfinition et de résolution des méthodes à l'exécution !

Pour les méthodes static perso je considère presque cela comme un défaut du langage (il faudrait interdire l'appel implicite de méthode static), car cela peut induire en erreur.


a++

[thelvin]

Pour les méthodes il y a aussi la notion de redéfinition et de résolution des méthodes à l'exécution !

C'est le polymorphisme, c'est corrélé à l'héritage dans la mesure où pour redéfinir une méthode, il faut déjà avoir le droit d'y toucher, mais c'est distinct. Notamment une méthode redéfinie peut encore être appelée par la sous-classe qui la redéfinit, via le mot-clé super.

Pour les méthodes static perso je considère presque cela comme un défaut du langage (il faudrait interdire l'appel implicite de méthode static), car cela peut induire en erreur.

Mon EDI n'a aucun mal à les afficher bien distinctes au premier coup d'œil, je ne risque donc pas spécialement d'erreur et j'aime bien ne pas devoir me palucher de savoir saisir le nom de la classe en cours. Mais je ne me fâcherais pas si on l'interdisait... Après tout c'est vrai qu'il y a aussi le problème des méthodes statiques portant le même nom.

[adiGuba]

Mon EDI n'a aucun mal à les afficher bien distinctes au premier coup d'œil, je ne risque donc pas spécialement d'erreur et j'aime bien ne pas devoir me palucher de savoir saisir le nom de la classe en cours. Mais je ne me fâcherais pas si on l'interdisait... Après tout c'est vrai qu'il y a aussi le problème des méthodes statiques portant le même nom.

Je voulais juste dire que cela porte à ambiguïté puisque la syntaxe ressemble à une méthode d'instance alors que ce n'est pas le cas... même si les EDIs peuvent différencier le code.
Perso j'aurais préféré que le langage interdise cela, en obligeant la syntaxe "NomDeClasse.method()" (ou l'import static).

Pire il y a même la syntaxe "instante.method()" qui est autorisé même pour les méthodes static...



Par contre tu as raison, les méthodes static des classes sont bien considérées comme un héritage de la classe parente http://docs.oracle.com/javase/specs/...html#jls-8.4.8


a++