> > * évite (sauf cas précis) d'écrire des méthodes prenant en paramètre un > objet "complexe". > > En parlant d'objet complexe je veux dire autre chose que des > String/Array/Hash/Integer/Float/BigDecimal. C'est un peu dans les bonnes > pratiques en développement de découpler et d'éviter des dépendances entre > les objets. Moins de dépendance = moins de problèmes (pour l'évolution, les > tests, etc). > > Donc plutôt que d'envoyer une instance de modèle à ton mailer, envoie lui > directement les chaînes dont il a besoin. > > Interessant ca. Je comprends ce que tu veux dire mais dans la pratique, j'avoue (assume) passer svt des objets complexes a mes mailers (et pas que la d'ailleurs). Pour plusieurs raisons:
1/ on m'a formaté pour ne pas avoir plus de 4 parametres pour une fonction (pb de perf en C mais j'imagine que cela doit etre la meme chose en Ruby + j'aime pas dans mon editeur je trouve ca pas beau). Or j'ai svt plus de 4 "variables" a utiliser dans un message d'un email (l'email, prenom, nom, ...etc), du coup, je prefere passer l'objet en question. 2/ le duck typing permet d'abstraire pas mal de choses (c'est comme manipuler des "interfaces") et ne pas se retrouver bloque a utiliser un seul type d'objet. non ? En fait, je me suis permis de repondre a ton message car depuis qq temps, je vois une tendance de fond parmi les developpeurs Ruby a utiliser pas mal de "patterns" ou de regles venant de Java en autre. Je pense notamment a l'IOC par exemple. J'ai rien contre mais la force / attractivite de Ruby au depart, c'etait qu'on n'avait pas forcement besoins de ces "patterns" pour faire du code beau et propre. -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected]
