I have a value object which has some attributes. In one scenario, all the values in the object needs to be reset. I am caught between 2 options, one to reset all the values (one by one) in the VO from another Form Handler or have a reset method in the VO itself and then invoke the reset method from Form Handler.
Pattern wise, I feel that having reset method in the VO is better, but am just not 100% sure if attaching reset to VO makes sense.
What exactly do you mean by "reset"? Do you have default values that are assigned to the object that you want to restore? Do you mean reset in the sense of an HTML form reset button, where the original values are restored?
I'm not aware of any particular pattern regarding "reset" capability. My rule of thumb would be to assign the responsibility to the object that is most intimate with the data but with the limited context that you gave, that rule of thumb may or may not apply.
Joshua Antony wrote:Basically the reset method just resets all the fields in the object to default value.Joshua
Then why bother with a reset method? I'd imagine that creating a new instance would be less of a hassle than having to write and maintain a reset method, so why not just get a new instance. That way, a constructor becomes your "reset".
Joined: Jun 05, 2006
Sorry, I should have been more specific, reset method resets MOST of the fields and not all fields.
Then my initial approach would still be to use a constructor that only copies the attributes that you don't want to reset, since there are fewer of those. Any other attributes would get the default values they get upon normal object instantiation. Like so:
Junilu Lacar wrote:Then my initial approach would still be to use a constructor that only copies the attributes that you don't want to reset, since there are fewer of those. Any other attributes would get the default values they get upon normal object instantiation. Like so:
I agree with this for a reason other than mere ease of programming. On a side note, I'm a fan of using a constructor that takes an object of the same class as a "clone" method.
Value objects should be immutable. Once you assign a value to a VO, you shouldn't change it. (I like to say this is a WORM (Write Once Read Many) object, but I can't seem to get that terminology to catch on.) The idea is that a single value object may be referenced by many client objects. Each one of those clients may have already made some determination between one VO and another. e.g. voM > voN for whatever notion of greather-than make sense. If you then change the value of voM, that relationship may no longer hold. No telling what chaos will then ensue.
If your objects are more complicated and changing their values makes sense, such as an Employee object changing hourly rates from $7.50 to $9.25, then it's not really a "value object". Speaking of VO properties, please make sure that if two of your VOs (say, voM and voN) are effectively equivalent, then voM.equals(voN) (and vice-versa) should be true. Also, voM.hashCode() had better equal voN.hasCode(). Again, if this doesn't make sense in your application, then you're not really talking about "value objects."
So, to answer the original question...
No, a value object should not have a reset method. I would even go as far as to say, "Heck no!" The fields should all be private with getters but no setters, and none of the methods should change the fields that make up the "value" of the object once the constructor set them to their initial values.