This week's book giveaway is in the OO, Patterns, UML and Refactoring forum.
We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes DTO - immutable vs mutable and accessors vs public variables Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "DTO - immutable vs mutable and accessors vs public variables" Watch "DTO - immutable vs mutable and accessors vs public variables" New topic

DTO - immutable vs mutable and accessors vs public variables

Piotr Nowicki
Ranch Hand

Joined: Jul 13, 2010
Posts: 610

Howdy Ranchers!

DTO is meant to hold the DATA only. So, did you:

- make all variables public (typical data structure - not an real-object)
- make all variables public and final (to get immutable data structure),
- generate getters and setters for every variable (typical JavaBean)
- generate only getters and let only the constructor to assign the values (something like immutable Object-data-structure).

Are your DTOs immutable? If so, do they have a default constructor (for serialization purpose)? If your DTO is immutable, what do you think the flow should look like for the future enhancement for functionality like the 'update' or 'create' functions. Create is an easy one - user can just create new object using new Room(.....).

But the update wouldn't be so nice like:
fetch object, update fields (by sets or variables directly), save. (mutable object)
It would be more:
fetch object, create new DTO with new values, save. (immutable object)

What do you think about this?

Roberto Perillo

Joined: Dec 28, 2007
Posts: 2270

Howdy, Pedro!

Well, I think it would make sense to make the Room object (which is the only DTO I see for this application) immutable if it was a value object. Value objects are objects that don't have an identity: if their values are equal, then they are equal. And they are also immutable. In a domain model, the Room class should be an Entity, but we don't have a room number to use as identity. What I'm trying to say is that it isn't worth to make it immutable. I myself created my Room class with a default constructor and all instance variables as private, and provided getter and setter methods to all of them.

Ah, and remember that, in case of a reference, if it is final, then you can still change the state of the object (if it provides getter and setter methods). You just can't change the reference itself.

Cheers, Bob "John Lennon" Perillo
SCJP, SCWCD, SCJD, SCBCD - Daileon: A Tool for Enabling Domain Annotations
Piotr Nowicki
Ranch Hand

Joined: Jul 13, 2010
Posts: 610

Thanks for your time and explanation Roberto!

I've decided to leave the room identifier in Room object, leave the setters and getters for every variable with an exception to the room identifier which is an Integer and has only the getter method. It can only be set during the construction of the object and as Integer is immutable, one cannot change it's value to anything else after object instantiation.
Roel De Nijs

Joined: Jul 19, 2004
Posts: 7233

I will add my approach here too: I just have public non-final data members inside my dto, so no getters/setters and values can be changed without any problem.

SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
I agree. Here's the link:
subject: DTO - immutable vs mutable and accessors vs public variables
It's not a secret anymore!