Discussion :

[Satch]

Je prépare gentiment la certif 1z0-805 (mise à jour vers java 7 programer)
Et là je tombe sur une question dans un bouquin qui me semble sujette à controverse :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
class base1 {
	protected int var;
}
interface base2 {
	int var=0; //#1
}
 
class Test extends base1 implements base2{ //#2
	public static void main(String[] args) {
		System.out.println(var); //#3
	}
}

les choix sont :
a) erreur à #1
b) erreur à #2
c) erreur à #3
d) pas d'erreur


J'ai répondu d. C'est la réponse qui me semblait la plus logique :
En effet, vu qu'on est dans un contexte static dans le main, "var" ne peut vouloir dire QUE la constante définie dans l'interface.

Et pourtant la bonne réponse est c.

Je ne comprends pas pourquoi le compilateur se plaint dans ce cas, puisque dans le code tel qu'il est écrit, "var" ne peut pas faire référence à l'attribut de "base1" puisqu'on n'a pas d'instance de cet objet.

Quelqu'un a une explication rationnelle à ceci ? J'imagine bien que cette erreur de compilation n'est pas là sans raison et a été réfléchie, mais je ne comprends vraiment pas la logique...

[kolodz]

L'attribut de ton interface est déclaré non static. Ce qui fait que ton interface déclare que tout objet implémentant "base2" aura un attribut (final) int var;Après en pratique, il est rare de voir un attribut déclaré non static dans une interface.

Cordialement,
Patrick Kolodziejczyk.

[thelvin]

Euh, non -_-°.

Les attributs déclarés dans une interface sont toujours public static final. Il n'est pas nécessaire de le dire explicitement dans la déclaration, puisqu'ils ne peuvent pas être autre chose. Pour rappel, une interface ne peut pas déclarer d'état, c'est l'un des principes du genre d'héritage multiple qu'elles permettent.
(Dans le même genre, toute méthode déclarée par une interface est public, et toute interface ou classe déclarée par une interface est public static)


Je ne sais pas vraiment pourquoi il y a erreur de compilation, mais je vais dire pourquoi je trouve ça logique :

C'est une mauvaise idée de faire varier les règles de résolution de noms de variable, suivant qu'on soit en contexte static ou d'instance. Là on est en contexte statique et donc une seule variable pourrait être la bonne, mais ça ne change rien au fait qu'il existe plusieurs variables, et qu'il n'y a pas que le contexte statique dans la vie. Le développeur pourrait avoir eu la variable d'instance en tête, et ne pas avoir remarqué qu'il est en contexte statique. L'ambiguïté qui justifie un message d'erreur est toujours là et bien là.
Quand on est pas dans un contexte statique, préciser de quelle variable on parle est obligatoire et clarifie l'intention. Puisque le mécanisme est là et qu'on doit le faire en contexte d'instance, on est en droit de se demander qu'y aurait-il de bien à ne pas le faire en contexte statique.
Certes, le compilateur pourrait toujours décider de choisir la seule variable acceptable. Mais le programmeur, c'est une autre histoire.

[kolodz]

Euh, non -_-°.

Les attributs déclarés dans une interface sont toujours public static final. Il n'est pas nécessaire de le dire explicitement dans la déclaration, puisqu'ils ne peuvent pas être autre chose.

J'ai pas dis le contraire...
J'ai juste dit que son attribut était non static. Même si je n'ai pas précisé le public Car tout est public dans une interface....

Il y a une erreur de compilation, car la méthode main est static, elle ne s'applique donc pas à un objet. Donc, les deux attributs ne sont pas visibles quoiqu'il arrive.

C'est une mauvaise idée de faire varier les règles de résolution de noms de variable, suivant qu'on soit en contexte static ou d'instance. Là on est en contexte statique et donc une seule variable pourrait être la bonne, mais ça ne change rien au fait qu'il existe plusieurs variables, et qu'il n'y a pas que le contexte statique dans la vie. Le développeur pourrait avoir eu la variable d'instance en tête, et ne pas avoir remarqué qu'il est en contexte statique. L'ambiguïté qui justifie un message d'erreur est toujours là et bien là.
Quand on est pas dans un contexte statique, préciser de quelle variable on parle est obligatoire et clarifie l'intention. Puisque le mécanisme est là et qu'on doit le faire en contexte d'instance, on est en droit de se demander qu'y aurait-il de bien à ne pas le faire en contexte statique.
Certes, le compilateur pourrait toujours décider de choisir la seule variable acceptable. Mais le programmeur, c'est une autre histoire.

Comme le dit @Satch la question est "sujet à controverse". C'est un exemple qui veux vérifier si la personne comprendre les mécanismes du langage Java, sans être un cas réel.

Cordialement,
Patrick Kolodziejczyk.

[thelvin]

Euh ? Je répète autrement ce que j'ai dit dans mon premier paragraphe :

Il n'est pas possible, pour un attribut d'interface, de ne pas être static.

[kolodz]

Autant pour moi, méconnaissance de ma part de la valeur par défaut pour les attributs.

Du coup, je rejoins l'avis de @Satch :
Contexte statique, Un variable statique, l'autre non :
Le compilateur devrait dans ce cas arrivé à faire la sélection.

Sachant que base1.var est inaccessible...

EDIT : Effectivement, ((après un warning aurait été suffisant dans ce cas.)) Dans tout les cas, le code écrit ne devrait jamais avoir lieu.