08-06-2015, 11:12 AM
Okay, mauvais exemple pour les billets, mais il peut exister plusieurs façons d'additionner deux données (formellement, on peut avoir plusieurs loi de composition interne pour un même type/ensemble de valueobject).
Par exemple:
Argent{100, $} + Argent{100,€} = ?
Je peux avoir une règle qui dit je fais l'addition ssi les sommes sont de même monnaie
Argent{100, $} + Argent{100,€} = <interdit (exception)>
Ou bien dire l'addition se fait dans la monnaie la plus forte
Argent{100, $} + Argent{100,€} = Argent{190, €}
Ou encore l'addition se fait dans la monnaie dont le symbole est le plus petit en UTF-8:
Argent{100, $} + Argent{100,€} = Argent{215, $}
Du coup, je dirai que oui, il y aura beaucoup de valueobject. Dans le cas d'un utilisateur, si cela s'avère nécessaire, il ne me semble pas abberant d'avoir un valueobject décrivant les données du user (genre pseudo, date d'inscription, mail,...) et un valueobject qui représente un user lui-même (avec ses méthodes de connexions, de droits ou autre). L'avantage serait alors de pouvoir réutiliser ce valueobject pour d'autres "types" de user.
Par exemple, on peut avoir la classe "User" en général, et "ClientUser" pour l'utilisateur qui demande la page courante. Celui-ci a besoin de sa méthode "connect()" pour être loggé, mais s'il visite la page de classement du jeu, il n'a pas besoin de la méthode "connect()" de chacun des User du jeu. Voire même, s'il est déjà connecté, sa méthode "connect()" est inutile.
Après, c'est comme d'hab: si c'est pas utile, c'est pas à faire. Une seule classe user avec ses données dedans, c'est possible aussi. Si l'encapsulation est correcte, on pourra extraire le valueobject de ce User et s'en reservir dans ClientUser, sans péter ce qui utilise User (tout comme on peu créer ClientUser et y intégrer l'attribut du User).
Par exemple:
Argent{100, $} + Argent{100,€} = ?
Je peux avoir une règle qui dit je fais l'addition ssi les sommes sont de même monnaie
Argent{100, $} + Argent{100,€} = <interdit (exception)>
Ou bien dire l'addition se fait dans la monnaie la plus forte
Argent{100, $} + Argent{100,€} = Argent{190, €}
Ou encore l'addition se fait dans la monnaie dont le symbole est le plus petit en UTF-8:
Argent{100, $} + Argent{100,€} = Argent{215, $}
Du coup, je dirai que oui, il y aura beaucoup de valueobject. Dans le cas d'un utilisateur, si cela s'avère nécessaire, il ne me semble pas abberant d'avoir un valueobject décrivant les données du user (genre pseudo, date d'inscription, mail,...) et un valueobject qui représente un user lui-même (avec ses méthodes de connexions, de droits ou autre). L'avantage serait alors de pouvoir réutiliser ce valueobject pour d'autres "types" de user.
Par exemple, on peut avoir la classe "User" en général, et "ClientUser" pour l'utilisateur qui demande la page courante. Celui-ci a besoin de sa méthode "connect()" pour être loggé, mais s'il visite la page de classement du jeu, il n'a pas besoin de la méthode "connect()" de chacun des User du jeu. Voire même, s'il est déjà connecté, sa méthode "connect()" est inutile.
Après, c'est comme d'hab: si c'est pas utile, c'est pas à faire. Une seule classe user avec ses données dedans, c'est possible aussi. Si l'encapsulation est correcte, on pourra extraire le valueobject de ce User et s'en reservir dans ClientUser, sans péter ce qui utilise User (tout comme on peu créer ClientUser et y intégrer l'attribut du User).