Valueobject

[srm]

Ok j'ai vu pour le Haskell c'est sympa
Du coup en Haskell les ValueObjects servent sans doute à rien vu qu'il y a un nouveau système de création de type pour faire ça.

[niahoo]

comment ça nouveau ?

[Xenos]

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).

[niahoo]

Mais si les méthodes sont dans le valueobject, comment cela se passe si un valueobject peut être associé à plusieurs algères? Par exemple, un valueobject décrivant un billet de banque avec sa valeur faciale, son numéro de série et sa date, peut être associé à plusieurs algèbres: on peut comparer les billets selon leur valeur faciale (assez naturel), leur numéro de série ou leur date d'impression.

Perso, j'aurai mis les 3 données dans un valueobject, créer les classes de calcul à part (1 part algèbre), dont j'aurai éventuellement décoré le valueobject.

Arf j'avais pô vu ta réponse.

Comme Ter Rowan je pense qu'un ValueObject devrait ne contenir qu'une valeur, potentiellement composée. 

Malheureusement, « valeur » est un terme assez flou, si on y réfléchit bien. Dans les langages OO, comme les classes servent de système de types et servent aussi à définir les fonctions manipulant ces types, n'importe quel ValueObject peut s'enrichir de nombreuses méthodes au fil du temps, ce qui entraînera, j'en suis sûr, l'ajout d'autres propriétés.

Du coup, il n'y a pas de frontière entre un ValueObject et un modèle User par exemple.

Du coup ... s'encombrer de valueObjects c'est s'encombrer de classes supplémentaires !

J'oubliais : ce pattern existe parce-que, je l'ai déjà dit, les langages OO n'ont pas de système de types et donc utilisent des instances de classes. Du coup la comparaison entre deux valeurs composées devient galère car les opérateurs comparent les identités. De tels objets permettent de faire des comparaisons de valeurs.


@srm du coup tu ne m'a pas répondu pour l'époque dans ton précédent post. Quant au « nouveau » système de types de Haskell il a été designé avant 1990. Donc j'ai l'impression que tu avances des choses, mais qu'au final ta vision est biaisée parce que tu ne connais que la programmation orientée objet, et que tu ne conçois la programmation que via ce prisme là.

[niahoo]

Pour la classe Argent tu utilises des décorateurs qui implémentent les différentes façon d'additionner, et tes classes métier travaillent généralement avec un seul de ces sous-types de valeurs. Effectivement ça fait pas mal de ValueObject différents. Et c'est là que en déclarer un seul par fichier devient chiant et que je déroge à la règle

[Xenos]

tu utilises des décorateurs qui implémentent les différentes façon d'additionner

D'acc, ca rejoins donc ce que je pensais (Perso, j'aurai mis les 3 données dans un valueobject, créer les classes de calcul à part (1 par algèbre), dont j'aurai éventuellement décoré le valueobject. )

[srm]

Pour moi un valueObject ne doit répondre qu'à ce cas là :
Argent{100, $} + Argent{100,€} = Exception

Il ne doit pas être assez intelligent pour savoir convertir des valeurs monétaires, sinon ça n'est plus une valeur, c'est bien plus intelligent qu'une valeur.

[niahoo]

Ben ça dépend de ce que représente ta monnaie. la monnaie peut très bien être exprimée en termes de ratio par rapport à une monnaie de référence (au hasard : le Dollar).

Code :

100 $ = 100 * 1
100 € = 100 * 1.38

Et on a un bête nombre composé.

Comme on dit ça dépend vraiment du domaine.

Bon je vois que tu ignores mes questions, je te fous la paix là dessus.

[Xenos]

Okay @srm, mais s'il n'a pas l'intelligence pour répondre à A+B (c'est pour cela que j'hésite entre différer l'intelligence de calcul dans une autre classe pour tous les cas ou seulement pour ceux où j'ai plusieurs intelligences), il ne doit pas l'avoir non plus pour répondre à A>B ou à A=B (il me semblait avoir vu de tes codes où ces comparaisons étaient dans le valueobject)?

[srm]

Désolé niahoo, je ne sais pas quoi répondre pour nouveau.
Bah pour > il se compare à lui même. C'est à dire un objet du même type.

La question revient pour moi a se dire : est-ce que l'on peut faire ça en valueObject
Pomme() + Orange() = Fruits(2)
Pour moi non