Je pousse toujours dans les retranchements, car mieux vaut y tomber tôt que tard, une fois le projet avancé 
RealDevise ne me semblait pas réalisable avant, sans cette notion de "UniformDevise".
La définition de DTO ok (je suis d'accord que rien ne l'oblige à être immutable, mais si on le veut immutable on le peut).
Celle d'objet, ok.
Celle de VO implique donc que je peux mettre tous les comportements de la Terre que je veux: un Objet avec un tas de comportement, mais qui serait immutable et dont deux instances distinctes peuvent être égale serait donc un VO?
Du coup, j'essaie de classer les types de... classes :
![[Image: ValueObjectAndDTO.png]](http://toile.reinom.com/wp-content/uploads/2015/09/ValueObjectAndDTO.png)
Là, pour toi les VO sont la partie IE (Immutable, Equality; qui inclut BIE) et les DTO la zone BE (Behaviorless, Equality; BIE inclus aussi). Donc un DTO mutable n'est pas un VO (mais un DTO Immutable est un sous-genre de VO)?
Du coup, si deux objets partagent un même VO (par exemple, Alice et Bob partagent Adresse={1, MainStreet, NewYork}) et que je veux changer ce VO pour déménager à Adresse={10, Liberty Street, Washingtown}, alors je vais devoir assigner cette nouvelle adresse à Alice et à Bob? S'il était mutable, j'aurai juste eu à changer le VO de l'Adresse, et tous ceux habitant à cette adresse auraient automatiquement déménagés.
Ce qui me gène dans l'immutable, c'est qu'un VO partagé entre plusieurs entités ne peut pas être mis à jour (si immutable). Un DTO peut facilement l'être (car mutable).
echo $eur->getUniformDevise() . ' $';
RealDevise ne me semblait pas réalisable avant, sans cette notion de "UniformDevise".
La définition de DTO ok (je suis d'accord que rien ne l'oblige à être immutable, mais si on le veut immutable on le peut).
Celle d'objet, ok.
Celle de VO implique donc que je peux mettre tous les comportements de la Terre que je veux: un Objet avec un tas de comportement, mais qui serait immutable et dont deux instances distinctes peuvent être égale serait donc un VO?
Citation :Le value object [permet] la manipulation d’objet dont le comportement est bien défini, au lieu de tableaux associatifs impossibles à testerUn tableau associatif est mutable et sans comportement, c'est plutôt un DTO qu'un VO.
Du coup, j'essaie de classer les types de... classes :
Là, pour toi les VO sont la partie IE (Immutable, Equality; qui inclut BIE) et les DTO la zone BE (Behaviorless, Equality; BIE inclus aussi). Donc un DTO mutable n'est pas un VO (mais un DTO Immutable est un sous-genre de VO)?
Du coup, si deux objets partagent un même VO (par exemple, Alice et Bob partagent Adresse={1, MainStreet, NewYork}) et que je veux changer ce VO pour déménager à Adresse={10, Liberty Street, Washingtown}, alors je vais devoir assigner cette nouvelle adresse à Alice et à Bob? S'il était mutable, j'aurai juste eu à changer le VO de l'Adresse, et tous ceux habitant à cette adresse auraient automatiquement déménagés.
Ce qui me gène dans l'immutable, c'est qu'un VO partagé entre plusieurs entités ne peut pas être mis à jour (si immutable). Un DTO peut facilement l'être (car mutable).