Le 8 février 2011 10:20, Guillaume Betous <[email protected]> a écrit : >> Le problème est justement dans ce que tu dis: " Mais je ne vois pas en >> >> quoi ça change quoi que ce soit, tant que name est une méthode ou un >> attribut du modèle author," Justement, l'objectif est de pouvoir >> changer l'implémentation d'un modèle sans avoir à impacter les autres. > > J'ai compris, mais je ne vois pas en quoi ça aide. Concrètement, ton > wrapper, comment le faire pour qu'il ne soit pas archi dependant ? > (si ça se trouve c'est de là que vient ma mécompréhension) >
Quoi qu'il arrive, à partir du moment ou un objet à une "interface" public, il y a forcement un impact quand tu modifies cette interface. Rien ne pourra changer cela, enfin, pas à ma connaissance. D'où cette loi qui permet au moins de ne pas impacter toute l'application (on dit aussi ne pas dévoiler l'architecture de ton application à tes objets) mais uniquement ceux qui sont "proches". Si tu souhaites approfondir sur le sujet de la responsabilité des objet et la façon dont ils échangent, tu peux regarder un peu du coté du DDD (Domain Driven Design), c'est beaucoup Javaiste, mais il y a des concepts interessant (que l'on retrouve ailleurs bien sur ;-)). http://en.wikipedia.org/wiki/Domain-driven_design http://tech.groups.yahoo.com/group/domaindrivendesign/ http://www.methodsandtools.com/archive/archive.php?id=97 Mais, pour y revenir, oui, dès que tu changes une méthode qui a une visibilité "public", tu as forcement du refactoring à faire chez ceux qui l'appel. -- Yannick Francois +33 683 785 716 <http://kantena.com> -- 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]
