Vous devriez certainement préférer créer un nouvel objet dans la grande majorité des cas. Problèmes de réaffectation de toutes les propriétés:
- Nécessite des setters publics sur toutes les propriétés, ce qui limite considérablement le niveau d'encapsulation que vous pouvez fournir
- Savoir si vous avez une utilisation supplémentaire pour l'ancienne instance signifie que vous devez savoir partout où l'ancienne instance est utilisée. Donc, si classe
A
et classe B
sont toutes deux des instances de classe passées, C
elles doivent savoir si elles passeront jamais la même instance, et si oui, si l'autre l'utilise toujours. Cela couple étroitement les classes qui, autrement, n'ont aucune raison d'être.
- Conduit à un code répété - comme l'a indiqué gbjbaanb, si vous ajoutez un paramètre au constructeur, partout où l'appel du constructeur échouera à la compilation, il n'y a aucun danger de manquer un point. Si vous venez d'ajouter une propriété publique, vous devrez vous assurer de trouver et de mettre à jour manuellement chaque endroit où les objets sont "réinitialisés".
- Augmente la complexité. Imaginez que vous créez et utilisez une instance de la classe dans une boucle. Si vous utilisez votre méthode, vous devez maintenant effectuer une initialisation séparée la première fois dans la boucle ou avant le début de la boucle. Dans les deux cas, vous devez écrire du code supplémentaire pour prendre en charge ces deux méthodes d'initialisation.
- Signifie que votre classe ne peut pas se protéger d'être dans un état invalide. Imaginez que vous avez écrit une
Fraction
classe avec un numérateur et un dénominateur, et que vous vouliez faire en sorte qu'elle soit toujours réduite (c'est-à-dire que le pgcd du numérateur et du dénominateur était 1). C'est impossible à faire si vous voulez permettre aux gens de définir le numérateur et le dénominateur publiquement, car ils peuvent passer par un état invalide pour passer d'un état valide à un autre. Par exemple 1/2 (valide) -> 2/2 (invalide) -> 2/3 (valide).
- N'est pas du tout idiomatique pour la langue dans laquelle vous travaillez, augmentant le frottement cognitif pour quiconque maintient le code.
Ce sont tous des problèmes assez importants. Et ce que vous obtenez en échange du travail supplémentaire que vous créez n'est ... rien. La création d'instances d'objets est, en général, incroyablement bon marché, de sorte que les performances seront presque toujours totalement négligeables.
Comme l'autre réponse l'a mentionné, le seul moment où les performances peuvent être une préoccupation pertinente est si votre classe effectue des travaux de construction considérablement coûteux. Mais même dans ce cas, pour que cette technique fonctionne, vous devez être en mesure de séparer la partie coûteuse des propriétés que vous réinitialisez, afin que vous puissiez utiliser le modèle de poids de mouche ou similaire à la place.
En guise de remarque, certains des problèmes ci-dessus pourraient être quelque peu atténués en n'utilisant pas de setters et en ayant à la place une public Reset
méthode sur votre classe qui prend les mêmes paramètres que le constructeur. Si, pour une raison quelconque, vous vouliez emprunter cette voie de réinitialisation, ce serait probablement une bien meilleure façon de le faire.
Pourtant, la complexité et la répétition supplémentaires qui s'ajoutent, ainsi que les points ci-dessus qu'il ne traite pas, sont toujours un argument très convaincant contre le faire, surtout lorsqu'il est comparé aux avantages inexistants.