Au contraire on conseil de faire des recopies de sécurité dans les setter, mais le mieux c'est tout simplement d'éviter autant que possible les setters
J'abonde en ce sens, trop souvent je tombe sur du code avec un constructeur vide, créant un objet dans un état incohérent et dont c'est au code derrière de s'assurer que l'objet est bon.
Un objet n'est pas une collection de valeurs sans aucune logique entre elle, c'est une entité qui doit être cohérente.
De même j'ai tendance à privilégier les membre finaux (final).
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Merci
Posté par fearan . En réponse au journal L’homme orchestre, partie 2 : écrire du code (en Java). Évalué à 3.
J'abonde en ce sens, trop souvent je tombe sur du code avec un constructeur vide, créant un objet dans un état incohérent et dont c'est au code derrière de s'assurer que l'objet est bon.
Un objet n'est pas une collection de valeurs sans aucune logique entre elle, c'est une entité qui doit être cohérente.
De même j'ai tendance à privilégier les membre finaux (final).
Il ne faut pas décorner les boeufs avant d'avoir semé le vent