• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

DTO - immutable vs mutable and accessors vs public variables

 
Ranch Hand
Posts: 623
1
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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!
 
Bartender
Posts: 2292
3
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 623
1
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Good night. Drive safely. Here's a tiny ad for the road:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic