Discussion :

[bulbo]

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é)

CQJVD

Si tu n'utilises pas de patterns t'es bad, has been, blah, re blah, loue soit les patterns, in patterns we trust

Combien de bou.. developpeurs se gonfle la tete avec des patterns, genre j'assure comme une bete j'en connais 30 differents et au premier accroc on les retrouve pleurant sur le forum.

Tester la connaissance des design patterns revient a tester le vocabulaire des developpeurs et absolument pas leur connaissance du langage ou du design objet.

Certains patterns sont tellement complexes qu'a moins d'avoir la description du truc sous le pif, peu de chance de le refaire de tete, ensuite le developpeur lambda va etre oblige d'articuler son design autour de cette usine a gaz et c'est la bien souvent que les rois des patterns commencent a avoir des soucis.

Et si par malheur tu oses proposer une solution elegante, objet et intelligente mais qui Oh blaspheme tape un poil dans le code propose du pattern divin, tu risque le bucher direct.

Les patterns sont une solution, pas LA solution on a aussi le droit de faire sans (ca s'appelle l'experience) et c'est tout aussi efficace et rapide fait par un bon developpeur.
Si tu es d'accord avec ca moi ca me va parfaitement.
Pour avoir deja jette un oeil sur les patterns, j'en ai deja applique certains sans le savoir a l'epoque, mais si un puriste regarde le code il va raler me disant mais pourquoi ta classe tu l'as pas appelee comme ca, et pourquoi tu as pas fait ca comme ca meme si t'en as pas besoin au cas ou, des fois que ...

Desole mais vous n'aurez pas ma liberte de coder (et de designer par moi meme )

Bulbo

[fbehnam]

14/16 pas mal mais incomplet pour tester un vrai developpeur.

j'ai deja ecrit des tests de recrutement et tu as tout interet à rajouter des design pattern dans ton questionnaire car en entretien avec client c'est une des premieres questions qu'ils posent..

[eclesia]

Tester la connaissance des design patterns revient a tester le vocabulaire des developpeurs et absolument pas leur connaissance du langage ou du design objet.
...
Desole mais vous n'aurez pas ma liberte de coder (et de designer par moi meme )

Bulbo, tu es un sage! un développeur n'est pas une machine.

[troll]
j'adore la tournure . Combien de fois je me suis fait prendre de haut par des etudiants universitaires quand ca parle info. moi et mon miserable bts. On se fait écraser parce qu'on a pas un diplome "top" informatique. c'est tellement de préjugés ...
vous n'imaginez pas le mal que ca fait de voir passer sous les nez des offres qui "techniquement" demande ce que vous savez mais vous retourne "bac+4/+5 minimum".
La solution est de le prouver, documents, projets et réalisations a l'appui. Alors excusez moi si je proteste contre une "pseudo" raison de départager 2 classes de développeurs à l'embauche.
[/troll]

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)

heureux de voir que ce n'est pas retenu.

[the-gtm]

Ce questionnaire c'est un peu le code de la route du java, c'est mieux de savoir répondre aux questions pour l'examen mais en pratique ça ne sert pas à grand chose.

Genre la question:

Code :

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

1
2
Point p;
p.dump();

En pratique tu as un compilateur qui va te donner le problème, avec un peu de chance tu as même un IDE qui te souligne immédiatement l'erreur.

Pour un recrutement, je ferais plus confiance à des questions générales/abstraites qu'à une vérification des connaissances en Java. Si le candidat est capable de réfléchir, il pourra apprendre les points qu'il lui manque en Java, par contre l'inverse...

En plus déclarer des variables avec des underscores c'est pas vraiment la convention en Java non ?

[bulbo]

En plus déclarer des variables avec des underscores c'est pas vraiment la convention en Java non ?

Sur ce point je ne dirai rien je fais pareil, ca me permet de savoir immediatement si il s'agit d'une variable d'instance ou pas et comme mes arguments je les appelle aQuelQueChose (aString, aPort, aName ...) je fais aussi la difference avec mes variables locales...

De vieilles habitudes venant d'autre langages je suppose.

Bulbo

[reseau-emploi]

Sur ce point je ne dirai rien je fais pareil, ca me permet de savoir immediatement si il s'agit d'une variable d'instance ou pas et comme mes arguments je les appelle aQuelQueChose (aString, aPort, aName ...) je fais aussi la difference avec mes variables locales...

De vieilles habitudes venant d'autre langages je suppose.

Bulbo

Effectivement de vieilles habitudes qui sont de bonnes habitudes...

Ce qu'il faut c'est que dans un meme projet, tous les developpeurs utilisent
les memes notations.

le m_ vient du fait que cela fait 4 ans que je suis dans un projet ou
des le depart c'etait comme cela.
C'est d'ailleurs une bonne habitude et cela permet de reperer
d'ou vient chaque variable quand on lit un code que l'on ne connait pas.

[reseau-emploi]

puisque le sujet a un peu devie sur les designs patterns..
Et qu'a l'origine c'est mon sujet, je me permets d'en parler également

Lire un bouquin sur les designs patterns c'est bien, cela donne des idées
pour bien architecturer ses projets objets.
MAIS, ce n'est pas la solution ultime et ca me saoule chaque fois
que je rencontre quelqu'un qui ne jure que par cela. Ca ressemble meme
parfois à une démarche sectaire...

Prenons l'exemple du pattern de décoration. il est utilisé dans l'api java
pour obtenir des conteneurs qui supportent le multi-threading.
Et bien si vous voulez faire une application rapide et multi-threade...
C'est une merde car cela rajoute une surcouche (un appel de méthode)
supplémentaire qui ralentit fortement l'application.

Ce pattern de décoration ne devrait pas être utilisé dans une api
proposant des structures de données.

Bref rien ne vaut la réflexion personnel pour une bonne architecture
pour tenir compte de l'ensemble des contraintes d'un projet.

(Un mot également sur l'intérêt d'avoir un vocabulaire commun quand
on discute d'architecture : cela fait plus de 10 ans que les design patterns
existent... pas 1 développeur sur 10 programmant en objet ne l'a lu.
C'est criticable mais c'est comme cela. Alors vocabulaire commun : mon oeil.
Ceux qui parlent en utilisant le nom des design patterns essaient plutot
en général d'en mettre plein la vue aux autres. Ca ne fait pas avancer
le schlimblick)