File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes OO, Patterns, UML and Refactoring and the fly likes reset method in value object - is it Ok pattern wise? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "reset method in value object - is it Ok pattern wise?" Watch "reset method in value object - is it Ok pattern wise?" New topic
Author

reset method in value object - is it Ok pattern wise?

Joshua Antony
Ranch Hand

Joined: Jun 05, 2006
Posts: 254
Hi,

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.

Joshua


SCJP,SCWCD, Into ATG now!
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4419
    
    5

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.


Junilu - [How to Ask Questions] [How to Answer Questions]
Joshua Antony
Ranch Hand

Joined: Jun 05, 2006
Posts: 254
Basically the reset method just resets all the fields in the object to default value. With "object that is most intimate with the data" , having the method in VO makes more sense.

Joshua
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4419
    
    5

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".
Joshua Antony
Ranch Hand

Joined: Jun 05, 2006
Posts: 254
Sorry, I should have been more specific, reset method resets MOST of the fields and not all fields.

Thank you
Joshua
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4419
    
    5

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:
Ryan McGuire
Ranch Hand

Joined: Feb 18, 2005
Posts: 988
    
    1
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.
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4419
    
    5

Ryan McGuire wrote:Value objects should be immutable.

Agreed. Classic example is the Money object. I don't think the OP was using the term in this sense though; I have met very few people who do (tip of the hat to you )
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: reset method in value object - is it Ok pattern wise?
 
Similar Threads
Regarding Entity beans and value objects
Bean value not retaining
Problems in Form reset button
Retaining Old value in JSF
duplicate form submission