This week's book giveaway is in the Design forum.
We're giving away four copies of Design for the Mind and have Victor S. Yocco on-line!
See this thread for details.
Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

DTO - immutable vs mutable and accessors vs public variables

 
Piotr Nowicki
Ranch Hand
Posts: 611
1
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?

Cheers!
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Piotr Nowicki
Ranch Hand
Posts: 611
1
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 9929
113
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic