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]

Répondre à