(07-06-2015, 09:59 AM)Xenos a écrit : 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à.