Valueobject

[Max72]

Merci pour ta relecture et ton commentaire, j'apprécie.
Je vais essayer de te répondre point par point :

faut-il que tous les attributs du value object soient égaux entre eux? Ou seulement certains?)

Tous, ça me semblait logique.

Cela ne représente pas la maison à cette adresse (qui existe toujours), mais l'adresse du personnage?

En effet, c'est bien l'adresse du personnage. C'est (comme j'ai répondu sur le blog) la définition d'un Value Object, il est immutable. Si tu souhaites modifier l'adresse du personnage, tu en créé une nouvelle.

Les 3 avantages présentées (vérifications internes à la classe, classes auto-explicite et type hinting) ne sont pas spécifiques aux Value Object, mais sont génériques à toute classe

Tout à fait d'accord. Mais dans ma phrase, je met ces arguments face à l'utilisation de données simples (entiers, tableaux, ..), je ne parle pas d'autres classes ou patterns.

Pas d'accord. Ok, ça peut servir pour faire de la concaténation de chaîne, mais si on veut la valeur réelle, on passe par le getter.

C'est vrai, c'est une erreur de ma part, surtout dans le cas de nombre. Je vais ajouter une fonction getNative() qui permet la récupération de la donnée brute.

Pour le reste, l'article est bien écrit 2

Merci, j'ai pris conseil de vos remarques sur le moteur de templates

Ca m'a amené sur un autre article, Value Object vs Data Transfer Object.

C'est marrant, parce que dans ton article, je cite :

A Value Object doesn't have any identity, it is entirely identified by its value and is immutable.

C'est la définition que j'en fais également, non ?

Enfin, je considère les DTO comme des simples conteneurs de données légers, sans vérification ni fioriture : On stocke la donnée, on la récupère ailleurs, point.

Merci