Egalité des attributs
Une question du coup: le ValueObject Temperature={0; °C} est-il égal au ValueObject Temperature={32, °F} ? Avec l'approche "attributs tous égaux", non. Avec l'approche logique "ça représente la même température", oui.
Ce qui gène en fait, c'est que "égalité des attributs" n'est pas un comportement externe, mais un fonctionnement interne. Peu importe le fonctionnement interne: deux ValueObject sont égaux s'ils représentent la même donnée vue de l'extérieur.
Mutable
Supposons un objet représentant un vecteur 3D (x,y,z). C'est mon value object. J'aimerai le doter de l'opérateur d'incrémentation vecteur++ qui aurait pour effet d'augmenter la longueur du vecteur de 1 (et donc, ses coordonées changent en conséquence). S'il est immutable, je ne peux pas le faire (alors que int++ existe). L'immutable limite un peu trop les choses à mon goût, mais il a l'avantage de limiter les comportements possibles de l'objet.
L'article VOvsDTO
Attention, car si effectivement l'article dit Un Value Object est défini par ses membres et est immutable ("A Value Object doesn't have any identity, it is entirely identified by its value and is immutable."), il précise aussi la définition du value objet: Un Value Object représente des données prédéfinies et peut s'assimiler à un Enum (A Value Object represents itself a fix set of data and is similar to a Java enum. A real world example would be Color.RED, Color.BLUE, SEX.FEMALE...").
Donc, Numero.BIS/.TER/.QUATER/QUINTER sont des ValueObject avec cette définition, et ils sont effectivement immutable (en tous cas pour moi). Mais l'adresse du joueur est-elle un Value Object au sens de cet article? Elle ressemble plus à un DTO pour moi, et là, c'est bien précisé que les setters y ont leur place (sous entendu, DTO est mutable).
Une question du coup: le ValueObject Temperature={0; °C} est-il égal au ValueObject Temperature={32, °F} ? Avec l'approche "attributs tous égaux", non. Avec l'approche logique "ça représente la même température", oui.
Ce qui gène en fait, c'est que "égalité des attributs" n'est pas un comportement externe, mais un fonctionnement interne. Peu importe le fonctionnement interne: deux ValueObject sont égaux s'ils représentent la même donnée vue de l'extérieur.
Mutable
Supposons un objet représentant un vecteur 3D (x,y,z). C'est mon value object. J'aimerai le doter de l'opérateur d'incrémentation vecteur++ qui aurait pour effet d'augmenter la longueur du vecteur de 1 (et donc, ses coordonées changent en conséquence). S'il est immutable, je ne peux pas le faire (alors que int++ existe). L'immutable limite un peu trop les choses à mon goût, mais il a l'avantage de limiter les comportements possibles de l'objet.
L'article VOvsDTO
Attention, car si effectivement l'article dit Un Value Object est défini par ses membres et est immutable ("A Value Object doesn't have any identity, it is entirely identified by its value and is immutable."), il précise aussi la définition du value objet: Un Value Object représente des données prédéfinies et peut s'assimiler à un Enum (A Value Object represents itself a fix set of data and is similar to a Java enum. A real world example would be Color.RED, Color.BLUE, SEX.FEMALE...").
Donc, Numero.BIS/.TER/.QUATER/QUINTER sont des ValueObject avec cette définition, et ils sont effectivement immutable (en tous cas pour moi). Mais l'adresse du joueur est-elle un Value Object au sens de cet article? Elle ressemble plus à un DTO pour moi, et là, c'est bien précisé que les setters y ont leur place (sous entendu, DTO est mutable).