Mouais, je ne suis pas tant d'accord avec la notion de "Le value object est un simple objet où la comparaison n’est pas basée sur son identité." (faut-il que tous les attributs du value object soient égaux entre eux? Ou seulement certains?), ni celle d'"Un value object est un objet ‘immutable‘, c’est à dire qu’une fois créé, il ne sera plus possible de le modifier.": dans l'exemple du Personnage, pourquoi "Adresse" ne serait pas modifiable? Cela ne représente pas la maison à cette adresse (qui existe toujours), mais l'adresse du personnage?
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. En revanche, dire "Passer par des getter/setter permet de faire des checks qu'un attribut public ne permet pas", ce serait cohérent (surtout en PHP où les attributs ne sont pas typés, donc un attribut publique peut vraiment contenir n'importe quoi).
Pour le reste, l'article est bien écrit
Ca m'a amené sur un autre article, Value Object vs Data Transfer Object.
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. En revanche, dire "Passer par des getter/setter permet de faire des checks qu'un attribut public ne permet pas", ce serait cohérent (surtout en PHP où les attributs ne sont pas typés, donc un attribut publique peut vraiment contenir n'importe quoi).
Citation :Remarquez l’implémentation de __toString pour pouvoir récupérer la valeur de l’objet sans getter, ça fait plus proprePas 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. Si on veut la valeur sous forme de chaine (qui pourrait donc inclure, par exemple, l'unité monétaire et dans certains pays celle(ci est avant le nombre façon $30), on passe par le __toString(). Les deux ont des portées différentes, et ne sont pas échangeables.
Pour le reste, l'article est bien écrit
Ca m'a amené sur un autre article, Value Object vs Data Transfer Object.