- 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?
OCP Java SE 6 Programmer, OCM Java SE 6 Developer, OCE Java EE 6 JSPSD, OCE Java EE 6 EJBD, OCE Java EE 6 JPAD, Spring 3.0 Core Professional.
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.
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.