Plus exactement pour la réflexivité, il y a d'une part l'introspection qui consiste à analyser le programme au cours de l’exécution (comme récupérer des infos sur les classes) et l'intercession qui consiste à le modifier(modifier le comportement des classes). C'est un outils extrêmement puissant mais aussi très dangereux si mal utilisé.

Les Design Pattern sont plus intéressant a étudier et mettre en pratique au niveau de la modélisation que du code, permettant ainsi de mieux les comprendre et de mieux pouvoir jouer avec, ceci totalement indépendamment du langage utilisé.

Sachant qu'une grande partie de l'API Java les utilise, ça peut toujours être utile de connaitre les principaux, et puis tu peut très bien les mettre en pratique dans de petits projets sans forcément passer des jours sur la modélisation.

Je n'ai pas dit le contraire )

*

hyrulink2 Voir le profil de hyrulink2
Posté le 24 avril 2011 à 21:41:59 Avertir un administrateur
Pourquoi tu n'est pas pour les design pattern? L'auteur du sujet veut s’améliorer visiblement et connaitre les DP est un bon moyen de progresser en POO.

Parce que je ne crois pas un débutant capable de s'en servir à bon escient. Mon expérience m'a montré qu'un jeune qui vient de lire le GOF ou le "head first" sur les pattern voit des pattern partout (patternite aigüe) ce qui donne des applications totalement sur-architecturées.
Du coup je suis réticent à conseiller un apprentissage spécifique des DP, je pense qu'avec la pratique, on finit par utiliser automatiquement ceux qui sont intéressants.

Oui comment les utiliser si on ne les connait pas ?

C'est pas plus mal de placer par une patternite aigüe dans sa vie de programmeur que de rester avec du code tout pourri non réutilisable, non lisible, etc.

"C'est pas plus mal de placer par une patternite aigüe dans sa vie de programmeur que de rester avec du code tout pourri non réutilisable, non lisible, etc."

Un bon programmeur doit être capable de faire du code lisible et réutilisable sans même avoir à connaître les design pattern. Les DP sont juste une aide, et l'un des risques du programmeur débutant c'est d'être perdu sans ses DP et de vouloir les utiliser plus que de raison.

Ca dépend ou tu veux creuser, si c'est pour tes cours passe de java-se (standar edition) a java-ee (entreprise-edition)
-servlet
-jsp
-EJB

Sinon comme conseillé tu peux (doit) voir la réfléxivité.

Si tu aimes le réseau tu peux allez voir du coté des stocket ou de RMI.

Si tu aimes les mobile vois du coté de Android. (programmation par composant)

Tu peux aussi voir du coté de aspectJ (programmation par aspect) ca c'est super. (utilisé en jee par des framework tel que Spring par exemple)

Utiliser des BDD en java.

Tu peux voir les applet (programme lancé dans un navigateur)
(a titre personnel la je fait un jeux en réseaux par applet)

Enfin bon en java déja sans voir de librairie tu peux a peut pret tout faire.

Disclaimer: Ce post est potentiellement un flame en reponse a ce que j'ai lu au dessus. J'exagere de facon intentionnel mon propos afin qu'il soit clair.

Personnellement, je n'ai jamais ete fan des design pattern. J'ai toujours pense que c'etait de la surtheorisation branlette de gens qui font de la programmation oriente objet. Les design patterns repondent a des probleme extremement precis. Et lorsque l'on rencontre le probleme resolu par le design pattern pour la premiere fois, on resoud le probleme en reinventant le design pattern lui meme sans meme savoir qu'il est connu.

A quoi bon connaitre les design pattern ? Certains diront que le but est de ne pas faire les erreur classique et d'utiliser directement l'architecture logicielle qui convient. Mais comment sait on quel modele convient ? Ca on le sait par experience de programmation et d'architecture de logiciel que l'on a fait avant, pas par la lecture d'un gros bouquin sur les design patterns.

La plupart des design pattern utile se retrouvent partout dans toutes les API. Et on comprend facilement ce qui se passe quand on utilise l'API. Avoir lu la description du design pattern auparavant n'est clairement pas utile parcequ'on l'aura oublie ou on ne le reconnaitra pas.

Voir un peu d'architecture logiciel lorsque l'on a deja fait plein de projet est evidement utile. Mais avant c'est, dans le meilleur des cas, juste du bla bla qui te passe au dessus de la tete. Et dans le pire des cas, on aboutit a des logiciels avec plus d'architecture que de code.

Savoir des design pattern me fait gagner beaucoup de temps en terme de conception. Tu les as appris intuitivement et sur le tas tant mieux, mais en pratique c'est toujours plus rapide de ne pas réinventer la roue en programmation non ?

"Avoir lu la description du design pattern auparavant n'est clairement pas utile parcequ'on l'aura oublie ou on ne le reconnaitra pas."

C'est dommage comme raisonnement ça revient à dire "apprendre ne sert à rien car on oublie". Or désolé mais si on se donne la peine d'apprendre on oublie pas.

Tbop2, tu confonds deux choses ici: l'apprentissage et la production. En production reinventer la roue est la stupide la plupart du temps. L'apprentissage passe par reinvente la roue. Tout le monde a un moment ou a un autre quand il veut apprendre re-ecrit quelquechose de connu. Quasiment tous les etudiants, reimplemente manuellement une liste chaine ou un arbre binaire de recherche. Tant que tu ne l'as pas suffisement d'experience pour comprendre ce dont il s'agit, il va te falloir l'ecrire pour comprendre comment et pourquoi ca marche. Tant que tu n'as pas eu besoin d'ajouter un element au milieu d'un tableau, tu ne comprendras pas pourquoi une liste chainee est interessante.

Les design pattern c'est pareil. Tant que tu n'as pas pondu un ou deux projets de taille raisonnable qui s'ecroule sous une architecture branlante, le livre n'aura aucun sens pour toi. Une fois que tu as l'experience de comprendre pourquoi tel pattern est interessant, la theorie en elle meme n'est plus si importante que ca a mon avis. Parceque soit il s'agit d'un cas que tu as deja rencontre et que tu sais donc deja traite, soit c'est un pattern trivial et c'est ce que tu aurais fait de toute facon, soit c'est un cas obscure. Donc a ce point, l'interet de l'apprentissage formel des design pattern me parait mince.

En resume, ce que j'essaie de dire est que les gens mettent les designs pattern sur un pied d'estal alors que ce n'est pas si important que ca. C'est bien de le voir a un moment. Mais certainement sur le tard de l'apprentissage, parce que a mon avis, au debut ca sert a rien.

""Tbop2 Voir le profil de Tbop2
Posté le 25 avril 2011 à 12:46:10 Avertir un administrateur
Oui comment les utiliser si on ne les connait pas ?

C'est pas plus mal de placer par une patternite aigüe dans sa vie de programmeur que de rester avec du code tout pourri non réutilisable, non lisible, etc. ""

Ah oui? Donc ne pas connaître les design patterns te condamne à faire de la merde? Franchement j'ai utilisé des Factory method, des singletons et des builders ou des strategy sans savoir que c'était des patterns répertoriés. Certains sont naturels en POO, c'est pas parce que tu ne les implémentes pas exactement comme décrit dans les bouquins (genre en ajoutant 1 classe abstraite et 5 classes pour éviter un switch(), pardon d'exagérer mais c'est parfois ça qu'on voit) que ton code n'est pas maintenable.

""Tbop2 Voir le profil de Tbop2
Posté le 25 avril 2011 à 18:44:12 Avertir un administrateur
Savoir des design pattern me fait gagner beaucoup de temps en terme de conception. Tu les as appris intuitivement et sur le tas tant mieux, mais en pratique c'est toujours plus rapide de ne pas réinventer la roue en programmation non ? ""

En pratique on fait jamais comme dans la théorie, y'a qu'à voir les étudiants qui sortent de l'uni et qui ont en tête le concept du 3/tiers par sur-abstraction. Tu les laisses partir là dedans, tu peux être sur qu'ils se plantent et que tu finis avec une application lente et inmaintenable.

D'ailleurs, même chez les professionnels, j'attends toujours qu'on me montre un domain model 100% OO sur un système relationnel (ce qui soi-disant est rendu possible par hibernate). C'est encore un mythe, un truc qu'on vend aux jeunes comme un St-Graal et qui aboutit à un gaspillage de ressources et à des compromis bancals. Quelle connerie de faire croire aux gens qu'ils peuvent être indépendants du système de stockage. Dans toutes les applications non triviales on voit que c'est pas vrai...