Discussion :

[leminipouce]

Code :

Qu'obtenez vous si compilez et éxecutez ce code

Pourquoi une erreur de compilation ?
p.dump(); devrait etre detecté aprés exécution comme NullPointerException non ?!!!!

J'ai foiré à la première question aussi ,quelle honte

Non. Ton compilateur te jette en te disant "The local variable may not have been initialize.

Ce que tu dis serait vrai si tu passait p en argument d'une méthode et que depuis cette méthode tu appelais dump.

Code :

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

1
2
3
4
5
6
7
Point(){Point p;
executeDump(p);
}
 
public void executeDump(Point p){
p.dump();
}

[adiGuba]

Pourquoi une erreur de compilation ?
p.dump(); devrait etre detecté aprés exécution comme NullPointerException non ?!!!!

Le code est le suivant :

Code :

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

1
2
Point p;
p.dump();

Les variables locales ne sont pas initialisées par le compilateur (contrairement aux attributs). Ainsi le compilateur te force à initialiser explicitement les variables locales avant leurs utilisations... comme ce n'est pas fait tu as une erreur de compilation ("the local variable may not have been initialized").

Pour compiler il aurait fallu avoir le code suivant :

Code :

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

1
2
Point p = null;
p.dump();

(et là tu aurais bien eu un NPE à l'exécution)

a++

[®om]

Non. Ton compilateur te jette en te disant "The local variable may not have been initialize.

Ce que tu dis serait vrai si tu passait p en argument d'une méthode et que depuis cette méthode tu appelais dump.

Code :

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

1
2
3
4
5
6
7
Point(){Point p;
executeDump(p);
}
 
public void executeDump(Point p){
p.dump();
}

Tu ne fais que décaler le problème, là il te jette sur executeDump(p)...

[leminipouce]

Tu ne fais que décaler le problème, là il te jette sur executeDump(p)...

Damn it, tu as raison !

C'est étrange pourtant, car il continue ainsi de te jeter si tu code ceci:

Code :

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

1
2
3
4
public void executeDump(Point p){
    p = new Point();
    p.dump();
}

Ce qui pourtant rend le code tout à fait correct. Non ?

PS : Milles excuses pour cette grossière erreur, et merci à AdiGuba d'avoir donné la vrai réponse et ®om de m'avoir corrigé !

EDIT: Au fait je me rends compte que je reste très flou ici. Le code que je donne n'ai pas correct... et l'explication est celle donnée par AdiGuba !

[bassim]

oui merci ,en fait ,le compilateur me l'a déjà faite plusieurs fois mais je ne me suis jamais attardé la dessus .

On apprends tous les jours sur ce Forum

[in]

Juste pour la question sur les threads, je pense que se serait plus clair d'écrire 1 et 2 à la place de FisrtThread SecondThread. ca serait moins dur à lire

[xv-mnt]

13/16 Mais j'ai tout fait en 6 minutes...

1- erreur sur le nombre d'itérations 1: 10 au lieu de 12
2- erreur sur l'exception lancée par le remove d'itérateur, mais je les utilise rarement
3- Une classe abstraite ne peut pas hériter de plusieurs classes abstraites ?? et ce n'est pas le mot

Code :

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

abstract

qui définit une classe abstraite ?
Il faudra m'expliquer, car si

Code :

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

abstract C extends abstract B

, et

Code :

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

B extends abstract A

, il me semble que C extends B ET A !
Sinon, comment définir une classe abstraite sans utiliser le mot-clé abstract ?

[reseau-emploi]

13/16 Mais j'ai tout fait en 6 minutes...

1- erreur sur le nombre d'itérations 1: 10 au lieu de 12
2- erreur sur l'exception lancée par le remove d'itérateur, mais je les utilise rarement
3- Une classe abstraite ne peut pas hériter de plusieurs classes abstraites ?? et ce n'est pas le mot

Code :

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

abstract

qui définit une classe abstraite ?
Il faudra m'expliquer, car si

Code :

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

abstract C extends abstract B

, et

Code :

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

B extends abstract A

, il me semble que C extends B ET A !
Sinon, comment définir une classe abstraite sans utiliser le mot-clé abstract ?

ce que l'on entends généralement par étendre plusieurs classe est étendre 2 classes à la fois comme cela est possible en C++

Cela donnerait un truc du genre class A extends B,C

[reseau-emploi]

Juste pour la question sur les threads, je pense que se serait plus clair d'écrire 1 et 2 à la place de FisrtThread SecondThread. ca serait moins dur à lire

J'ai pris en compte te remarque et modifié la question comme tu le proposes

Merci

[reseau-emploi]

hello,

j'ai mis en place une page avec le résultat de l'ensemble des participants...

http://www.reseau-emploi.com/tests/test-java.php

Le graphe des résultats fait apparaitre une double courbe de Gauss.

Il y a d'un côté ceux qui connaissent un peu java (vu en cours par
exemple) et qui ont des notes entre 4 et 7
Et de l'autre ceux qui connaissent vraiment java : notes entre 9 et 13

Bref, ceux qui ont plus de 13 sont vraiement très bons

[zekey]

Salut, le test est marrant (j ai fais 13 mais pour ma défense j ai oublié une question ). Mais comme dans le SCJP je trouve que le test manque de questions sur le design. Grosso modo il garantit plus ou moins que la personne testée a deja fait du java; voire meme beaucoup de java mais pas forcément correctement.

Pourquoi pas des questions sur la programmation orientée object ou meme sur les design patterns, du genre : dans ce cas de figure quel design pattern utiliseriez vous.

[eclesia]

Pourquoi pas des questions sur la programmation orientée object ou meme sur les design patterns, du genre : dans ce cas de figure quel design pattern utiliseriez vous.

Ca c'est une injustice, c'est jouer avec les mots... c'est vilain pour les autodidacts qui n'ont pas le vocabulaire apprit en cours mais qui ont tout de même des compétences. Et inversement ce n'est pas parcequ'on connait le vocabulaire qu'on connait pour autant le java.

par exemple moi , je ne sais que depuis un petit mois que ce que je fais (les ecouteurs, listeners etc..) s'appelle un pattern observer. (et encore je suis pas sur de bien comprendre ce terme).

[zekey]

Ca c'est une injustice, c'est jouer avec les mots... c'est vilain pour les autodidacts qui n'ont pas le vocabulaire apprit en cours mais qui ont tout de même des compétences. Et inversement ce n'est pas parcequ'on connait le vocabulaire qu'on connait pour autant le java.

par exemple moi , je ne sais que depuis un petit mois que ce que je fais (les ecouteurs, listeners etc..) s'appelle un pattern observer. (et encore je suis pas sur de bien comprendre ce terme).

Soit mais seulement si tu fais du design avec une équipe tu dois pouvoir communiquer avec elle et pour cela il faut du vocabulaire commun. Tout du moins sous forme de diagramme, UML par exemple. Si tu as un probleme donné a résoudre et deux ou trois diagramme de classe, de mon point de vue c'est important de savoir les interpréter et le implementer.

[reseau-emploi]

Pourquoi pas des questions sur la programmation orientée object ou meme sur les design patterns, du genre : dans ce cas de figure quel design pattern utiliseriez vous.

Tout simplement parce que ce ne serait plus un test sur le langage java.
(on pourrait mettre les memes questions dans un test C++ ou tout
autre langage objet)

Par contre, je pense a faire un test sur les design patterns...Si certains
veulent participer ce serait avec plaisir.

[Kh4iN3]

Salut,

Vraiment tres interessant comme test bravo.
13/16....erreur à la question 2....j'avais oublié le dernier i++.....

a+

[NicoV]

Je viens d'essayer, mais il y a un bug.
Dernier corrigé : Quelle affirmation est fausse à propos des classes abstraites ? (je n'ai pas eu cette question, mais Quelle affirmation est fausse à propose des interfaces)
Corrigé: une réponse
Ma réponse: rien (normal puisque je n'ai pas eu cette question)

Refait une 2e fois, et pas de pb

[bulbo]

Soit mais seulement si tu fais du design avec une équipe tu dois pouvoir communiquer avec elle et pour cela il faut du vocabulaire commun. Tout du moins sous forme de diagramme, UML par exemple. Si tu as un probleme donné a résoudre et deux ou trois diagramme de classe, de mon point de vue c'est important de savoir les interpréter et le implementer.

Et tu fais comment lorsque tu as appris a coder bien avant l'apparition des patterns, on faisait comment crois-tu en cette epoque reculee ou la roue venait a peine d'etre inventee ?

Personnellement je travaille avec des gens qui ne jurent que par les patterns, a tel point que l'on se retrouve avec des implementations a la virgule pret, a croire qu'ils sont incapable de pondre un code original, ni de voir qu'ils ont introduit une complexite completement inutile dans le contexte

Et tu peux toujours leur en faire remarque, tu as droit au meme eternel couplet, le pattern dit que ..., le pattern est grand, le pattern est beau ...

Lorsque j'ai appris a coder objet il n'y avait pas de patterns, alors au lieu d'apprendre betement une ou deux solutions par coeur, on a appris a ne pas faire n'importe quoi au niveau design. Si je devais utiliser des patterns (deja faudrait que je les apprenne et ca me gonflerait) j'ai l'impression que je perdrais plus de temps qu'autre chose, la difference c'est que mon design est la reponse exacte au probleme initial et non une reponse generique pouvant coller a un trillion de probleme, du coup j'ose esperer qu'elle est un poil plus efficace.

Vala mon avis a 2 balles,

Bulbo

[deltree]

+1 sur bulbo, je préfère les solutions originales aux patterns be^te et méchants.

pour revenir au sujet: 12/16 et c'est pas parce que j'ai fait faux mais à la question 2, je trouve que c'est vraiement un piège et que ça n'apporte pas grand chose sur les capacité algorithmique de quelqu'un: d'une manière générale, c'est un peu trop technique et procédural, et pas assez objet et conceptuel.

typquement pour la 2: c'est codé à la porc: on fait un break, et on sait la valeur qu'on obtient

mais pour avoir tenté de réaliser un test, je sais comme c'et difficile, alors c'est quand même bieng

edit:
j'ajoute de petits commentaires: des connaissance des classes de bases pourrait être un plus: pourquoi préférer ArrayList à Vector, pourquoi typer ses variables de l'interface "List" plutot que du type final ArrayList..

[®om]

deja faudrait que je les apprenne et ca me gonflerait

Tu es sûr que ça n'est pas la raison qui fait que tu n'aimes pas les patterns: tu ne les connais pas

Un pattern, ça ne "s'apprend" pas, en fait tu réfléchis à un problème pour trouver une solution correcte (pour que ton appli soit bien structurée), et (si tu connais certains patterns) tu t'aperçois que la solution proposée est au moins aussi bonne que celle que tu avais imaginé... souvent meilleure...
Une fois que tu auras utilisé une fois un pattern, quand tu rencontreras le même problème, tu le réutiliseras... D'ailleurs je suis sûr que c'est ce que tu fais déjà, si t'as déjà résolu un problème d'une certaine manière, si tu rencontres le même problème, tu appliques la même solution... Sauf qu'avec les design patterns les solutions ont été bien réfléchies par beaucoup de monde (et par une personne de plus une fois que tu l'auras utilisé)

[zekey]

Le but n'était pas de lancer un Troll sur les patterns mais plutot de dire que plus important que les skills brut en java du genre connaitre par coeur l'API, il y a la capacité à designer.