Reprise du message précédent :

Oui, c'est équivalent à une struct C ou un record, c'est un objet/une classe qui n'existe que pour stocker des données mais n'a pas de comportement (méthodes, messages, ...)

ok.
 
c'est la voir dans laquelle je me dirigeais au début.
je vais suivre ca (tant pis pour les design patterns et autres )
 
 
je reviendrais si besoin
 
merci

Les design patterns, ce sont des solutions génériques à des problèmes récurrents, faire du design pattern pour faire du design pattern ça n'a aucun intérêt, surtout quand ça complexifie le logiciel

ouais...
 
là mon but est un peu pédagogique quand même.
c'est pour ca que j'ai (un peu) insisté sur les design pattern; je voulais tater un peu le truc pour voir comment on s'en sert et ce que ca apporte par rapport aux méthodes "classiques" (un peu à l'arrache parfois)
 
je veux avant tout un code lisible (compréhensible) et évolutif
Je pense pas que les design pattern soient super facilement compréhensibles, mais j'imagine qu'ils aident pour l'évolution du code.
 
Enfin on verra bien
 
rien n'empechera de voir les choses autrement plus tard

C'est pas nécessairement super facile à comprendre quand on les apprend, mais une fois qu'on les a appris et un minimum compris:
 

• Même si les détails d'implémentation peuvent différer, la "forme" globale de l'implé d'un pattern ne varie que peu, donc quand on voit cette forme dans du code on sait quel pattern a été appliqué, et donc quel problème a été résolu. Avec du bol (càd si le pattern a été correctement utilisé)
• Ca donne un vocabulaire commun, c'est d'ailleurs le but originel des Design Patterns en architecture (pas logicielle), créer un vocabulaire de haut niveau clarifiant des solutions standard à des problèmes courants.