Je suis pas super d'accord avec le fait de passer les chaines. Si tu as ne serait-ce qu'une vingtaine de propriétés à passer, question lisibilité, maintenabilité, productivité, ca bloque.
Tu peux passer un hash, mais le problème suivant se pose: qui prépare le hash? Le modèle, qui doit alors implémenter autant de méthodes qu'il a de représentation, un wrapper (donc autant de wrapper que de représentations) ou le controller? Dans le dernier cas, le mailer est une sorte de "controller", donc il parait tout à fait convenable de lui passer des "objets complexes". En plus, en ruby, tout est "objet complexe", du coup ... Autrement: *les patterns ne sont pas liés à un langage*. Je l'écris en gras parce que c'est important. Le IOC est très utilisé en J2EE mais ce n'est pas propre à Java. En fait, Java est un langage qui contient un énorme travail conceptuel du fait de son typage strict. En ruby, soit le langage permet de répondre à un problème autrement qu'en utilisant un pattern "classique", soit l'implémentation est moins évidente d'un point de vue extérieur. Pourtant si tu regardes bien, tu trouveras le pattern Singleton, des Proxy de partout (notamment dans Active Record), des Factory et bien d'autres. Un pattern est une solution pour un problème donné. Peut être qu'un langage peut permettre de ne pas voir émerger certains problèmes, mais ca doit rester marginal je pense. Utiliser un pattern, ca veut donc dire que tu ne perds pas du temps à élaborer une solution qui existe déjà et tu t'assures que tout le monde comprendra ton code s'ils connaissent le pattern, peu importe le langage. Le 25 mars 2012 19:42, Thibaut Assus <[email protected]> a écrit : > Espèce d'Epita va ;) > > Le samedi 24 mars 2012 21:56:42 UTC+1, Didier Lafforgue a écrit : > >> * é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] > -- 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]
