You should definitely prefer creating a new object in the vast majority of cases. Problems with reassigning all properties:
- Requires public setters on all properties, which drastically limits the level of encapsulation you can provide
- Knowing whether you have any additional use for the old instance means you need to know everywhere that the old instance is being used. So if class
A and class
B are both passed instances of class
C then they have to know whether they'll ever be passed the same instance, and if so whether the other one is still using it. This tightly couples classes which otherwise have no reason to be.
- Leads to repeated code- as gbjbaanb indicated, if you add a parameter to the constructor, everywhere that calls the constructor will fail to compile, there's no danger of missing a spot. If you just add a public property, you'll have to be sure to manually find and update every place where objects are "reset".
- Increases complexity. Imagine you're creating and using an instance of the class in a loop. If you use your method, then you now have to do separate initialization the first time through the loop, or before the loop starts. Either way is additional code you have to write to support these two ways of initializing.
- Means your class can't protect itself from being in an invalid state. Imagine you wrote a
Fraction class with a numerator and denominator, and wanted to enforce that it was always reduced (i.e. the gcd of the numerator and denominator was 1). This is impossible to do nicely if you want to allow people to set the numerator and denominator publicly, as they may transition through an invalid state to get from one valid state to another. E.g. 1/2 (valid) -> 2/2 (invalid) -> 2/3 (valid).
- Isn't at all idiomatic for the language you're working in, increasing the cognitive friction for anybody maintaining the code.
These are all pretty significant problems. And what you get in return for the extra work you create is... nothing. Creating instances of objects is, in general, incredibly cheap, so the performance benefit will almost always be totally negligible.
As the other answer mentioned, the only time performance might be a relevant concern is if your class does some significantly expensive work on construction. But even in that case, for this technique to work you'd need to be able to separate out the expensive part from the properties you're resetting, so you'd be able to use the flyweight pattern or similar instead.
As a side note, some of the problems above could be mitigated somewhat by not using setters and instead having a
public Reset method on your class which takes the same parameters as the constructor. If for some reason you did want to go down this reset route, that would probably be a much better way of doing it.
Still, the additional complexity and repetition that adds, along with the points above that it doesn't address, are still a very persuasive argument against doing it, especially when weighed up against the nonexistent benefits.