Le 19/09/2012 21:12, Guirec Corbel a écrit : > Bonjour à tous, > > Voici un exemple de code : > class Person < ActiveRecord::Base > has_many :hobbies > end > > class Hobby < ActiveRecord::Base > belongs_to :person > end > > Admettons que je veuillez ajouter un hobbie à une personne je peux > faire ça : > > person.hobbies.add(hobby) > > Mais je viole le principe d'encapsulation qui voudrais que je fasse ça : > > class Person < ActiveRecord::Base > has_many :hobbies > def add_hobby(hobby) > hobbies.add(hobby) > end > end
Non, je ne pense pas que tu violes le principe d'encapsulation. Person#hobbies est un proxy qui donne accès à toutes les fonctionnalités liées à l'association entre Person et Hobby définies par le has_many. Ajouter une méthode supplémentaire n'ajoute strictement rien sur le plan de l'encapsulation puisque de toutes façons hobbies reste accessible (et n'est donc pas à proprement parler encapsulé). Tu aurais ajouté du code pour rendre hobbies private, on aurait pu parler d'encapsulation (ce qui ne veut pas dire que c'est une bonne chose par ailleurs). Le proxy lui-même fait déjà un travail d'encapsulation en masquant les détails d'implémentation des interfaces qu'il définit. Personnellement je ne vois pas de besoin à restreindre encore plus les fonctionnalités accessibles. Le but de l'encapsulation est d'éviter de rendre un objet fragile en définissant des interfaces dont le comportement ne risque pas d'être influencé par des modifications directes de l'état de l'objet. AssociationProxy répond déjà à ce besoin, donc inutile de chercher la complication. a+ Lionel -- 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]
