Compréhension exercice certification Java

Bonjour,
je suis en train de regarder les exos du chap2 et meme par son explication je ne comprends pas bien :

voici cette exercice :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

classe A{} classe B extends A {} public class toto { static String s="-"; public static void main (String[] args){ A aa = new A[2]; B ba = new B[2];   titi(aa); titi(ba); titi(7); System.out.println(s); }   static void titi(A[]... a2) {s+="1"}; static void titi(B[]... b1) {s+="2"}; static void titi(B[] b1) {s+="3"}; static void titi(Object o) {s+="4"}; } et j'ai le choix entre les 4 résultats : -124 -134 -424 -434 -444

---

La réponse est 434 mais je ne comprends toujours pas pourquoi on choisi la réponse 3 et 4
On partirait que l'on overload du plus général au plus spécifique donc de l'Object vers un tableau qui est en principe défini comme un objet alors pour choisir la réponse 4 pour le int 7?
je dois dire que c'est assez confus
pourriez-vous m'aider?

Citation:

---

Envoyé par prugne

On partirait que l'on overload du plus général au plus spécifique donc de l'Object vers un tableau qui est en principe défini comme un objet alors pour choisir la réponse 4 pour le int 7?
je dois dire que c'est assez confus

---

En effet, je n'ai pas compris ta phrase du dessus.

Mais bon, pour le int 7 c'est évident : int n'est pas un sous-type de A[] ni de A[][] ni de B[] ni de B[][]. Il ne peut pas non plus être implicitement converti en un sous-type de l'un d'eux.

Par élimination, les méthodes 1, 2 et 3 sont rejetées d'office, il reste donc la 4.

Pour l'entier "7", depuis Java 1.5, il y a de l'auto-boxing.
Le "7" de type "int" est changé automatiquement en objet java.lang.Integer.
La seule méthode "titi" capable de prendre un Integer en paramètre est la "4".

j'ai compris pour le int 7
et pourquoi la réponse ne serait pas plus : 334 concernant le choix des méthodes pour les tableaux de type A et B ?

Comme sa je te dirais que si tu as un 3 c'est que l'objet est du type B[], alors que ton premier objet c'est aa de type A[], donc tu n'auras jamais un début avec 3.

Tu as fais une petite erreur de retranscription aux lignes 7 et 8. Tu devrais plutôt avoir ceci :

Code:

---

1 2 3

A[] aa = new A[2]; B[] ba = new B[2];

---

Pour répondre à ta question, la réponse ne peut pas être 334 pour plusieurs raisons.

Tout d'abord, nous avons affaire à des tableaux. Or, si A hérite de B, A[ ] n'hérite pas de B[ ] !!! Les tableaux, quel que soit leur type, héritent directement et uniquement de Object.

Ensuite, dans l'hypothèse où nous aurions affaire à des objets simples et non à des tableaux, c'est B qui hérite de A. Donc une méthode titi(B) ne pourrait pas être appelée en lui passant une instance de A. C'est l'inverse qui est possible, appeler une méthode titi(A) en lui passant une instance de B.

;)

Citation:

---

Envoyé par verbose

Tout d'abord, nous avons affaire à des tableaux. Or, si A hérite de B, A[ ] n'hérite pas de B[ ] !!! Les tableaux, quel que soit leur type, héritent directement et uniquement de Object.

---

Holà !
A[] n'est pas un sous-type de B[], mais B[] est bel et bien un sous-type de A[] puisque B extends A.

Citation:

---

Envoyé par thelvin

Holà !
A[] n'est pas un sous-type de B[], mais B[] est bel et bien un sous-type de A[] puisque B extends A.

---

Effectivement, après vérification B[ ] hérite bien de A[ ] si B hérite de A. J'ai toujours cru que ce n'était pas le cas. Désolé pour la bourde :aie:

Citation:

---

Envoyé par verbose

Effectivement, après vérification B[ ] hérite bien de A[ ] si B hérite de A. J'ai toujours cru que ce n'était pas le cas. Désolé pour la bourde :aie:

---

Je ne sais pas si on peut parler d'héritage, mais l'un est un sous-type de l'autre.

Je ne crois que le terme héritage peut s'appliquer sur des tableaux...
D'ailleurs il me semble qu'il n'est pas possible de faire un cast d'un tableau non?

bon comme ça j'aurais dit 134
urgh:aie:
tout viens des règles de levée des ambiguités lorsqu'il y a surcharge.
si une méthode est définie comme f(A[]... arg)
on peut l'invoquer avec un seul argument de type A[] (donc 1)
MAIS
en cas d'ambiguité (ici avec la surcharge qui prend Object) le compilateur se comporte en prenant en priorité ce qui se serait passé en version pre 1.5!)

Donc:
1) l'introduction tardive de varargs a conduit à des trucs bizarres
2) ne pas s'encombrer l'esprit avec ce genre de détail oiseux

je rajoute que, à cause de ces ambiguités, il n'est par recommandé d'avoir une méthode avec un vararg et une autre méthode, sans vararg, qui serait compatible (typiquement ici Object pour remplacer le vararg).

Les règles d'attribution disent simplement (si ma mémoire est bonne) qu'on attribue à un vararg uniquement si on n'a pas pu attribuer à rien d'autre.

Citation:

---

Envoyé par tchize_

Les règles d'attribution disent simplement (si ma mémoire est bonne) qu'on attribue à un vararg uniquement si on n'a pas pu attribuer à rien d'autre.

---

Hélas, ce n'est pas si simple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

public static void test(Object o) { System.out.println("test(Object)"); }   public static void test(String... strings) { System.out.println("test(String...)"); }   public static void main(String[] args) { String[] strings = new String[8]; test(strings); }

---

Pourtant, test(Object) aurait parfaitement accepté un String[].
Mais en tant que type tableau, Java favorise l'emploi du vararg.

Il y a une certaine logique : sans cela, il n'y aurait aucun moyen d'appeler test(String...) autrement qu'en fournissant littéralement au moins deux Strings. Dans le cas d'une seule String, ou bien d'un nombre inconnu à l'avance de Strings, on serait obligé de passer par la réflectivité, pour s'en servir.
Alors que comme ça, il suffit de construire un tableau. Si on préfère test(Object) pour ce tableau, on peut le cast en Object.

:aie:

Bon ben dès que je trouve une corde, je vais me pendre. En tout cas ça confirme la bonne pratique avec les varargs: ne pas laisser de choix possible au compilateur, éviter les apis ambigues :calim2:

Citation:

---

Envoyé par tchize_

:aie:

Bon ben dès que je trouve une corde, je vais me pendre. En tout cas ça confirme la bonne pratique avec les varargs: ne pas laisser de choix possible au compilateur, éviter les apis ambigues :calim2:

---

On peut se retrouver avec des trucs marrant à la sortie sinon ^^
C'est typiquement le genre de test qu'on retrouve à l'embauche ou dans les certifs et qui ne sert absolument à rien pour moi.

Bah, j'aurais tendance à l'embauche à donner un +1 au gars qui barre ça en disant "code de cochon" :aie:

Moui... On peut répondre qu'on refuse de savoir ce que ça fait parce que ça devrait jamais être fait comme ça! :mouarf:

ou que ce genre de détail fumeux ne mesure pas les compétences. Il ne sert qu'à faire plaisir à ceux qui sont tout content d'avoir exhibé un piège dans java et à ceux qui se réfugient dans ce genre de tests parce que, au fond, ils ne savent pas vraiment évaluer les compétences de quelqu'un...
Dire ça de manière juste sans passer pour une personne hautaine et méprisante est tout un art qui vous qualifie pour le poste!
(euh ... la rédaction de ce billet n'est donc pas un bon exemple! :aie:)

J'ai fait ce genre de truc à une interview
"Alors, voilà le résultat de votre test psychologique, pourriez-vous le commenter?"
"Non"
"Comment ça non?"
"Mais commentaires seraient désobligeants envers les personnes ayant réalisé ce test"

Citation:

---

Envoyé par tchize_

J'ai fait ce genre de truc à une interview
"Alors, voilà le résultat de votre test psychologique, pourriez-vous le commenter?"
"Non"
"Comment ça non?"
"Mais commentaires seraient désobligeants envers les personnes ayant réalisé ce test"

---

Aaaa le test pour le plaisir de tester! Toute une histoire :mrgreen: