SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Roel De Nijs wrote:1/ no getters/setters in the transfer object
Roel De Nijs wrote:2/ String[] does not contain the record number, the record number is passed seperately
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Sean Keane wrote:
Roel De Nijs wrote:1/ no getters/setters in the transfer object
Interesting that you've no getters\setters - am I correct in thinking that means a client who receives your transfer object can modify the record number and send it back to the server? Is that not a concern?
Sean Keane wrote:
Where were your two methods to convert the transfer object to/from an array - were they in the transfer object class?
Roel De Nijs wrote:2/ String[] does not contain the record number, the record number is passed seperately
I'm not sure if you are talking about your DB API here or your conversion methods. Does that mean that:
* Your method to convert an String[] array to a Room object has two parameters - the String[] object and an integer record number?
* Your method to convert a Room object to a String[] did not contain the record number in the String[] ?
SCJP 5, SCWCD 5, SCBCD 5
Sean Keane wrote:Interesting that you've no getters\setters - am I correct in thinking that means a client who receives your transfer object can modify the record number and send it back to the server? Is that not a concern?
Sean Keane wrote:Where were your two methods to convert the transfer object to/from an array - were they in the transfer object class?
Sean Keane wrote:I'm not sure if you are talking about your DB API here or your conversion methods.
Roel De Nijs wrote:
Sean Keane wrote:Interesting that you've no getters\setters - am I correct in thinking that means a client who receives your transfer object can modify the record number and send it back to the server? Is that not a concern?
Yes, you are correct! Why would that be a concern? You may expect of a developer that he knows what he's doing, so if he decides to change the record number of a room transfer object always to 1 that's his choice.
Roel De Nijs wrote:
Sean Keane wrote:I'm not sure if you are talking about your DB API here or your conversion methods.
All String[] in my application are the same size (and they do not contain the record number, because there's no need to), so the assumptions you made are both correct.
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Sean Keane wrote:The same reason you make some methods private - because you don't want a user of your API to be allowed call them.
Sean Keane wrote:You don't expect or want a user of your API to set the record number
Sean Keane wrote:Why leave this possibility for someone being mislead, using your API not as you intended, or errors occuring when you can code against it by preventing the record number from being modified. It seems like a no-brainer.
Roel De Nijs wrote:
Sean Keane wrote:The same reason you make some methods private - because you don't want a user of your API to be allowed call them.
True, but only methods which are guaranteed never to be called are made private (e.g. reading/writing 1 record from/to database file).
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Sean Keane wrote:Is there any good reason why you would not guarantee that a user of your API can never set the record number of a Room object?
Roel De Nijs wrote:
Sean Keane wrote:Is there any good reason why you would not guarantee that a user of your API can never set the record number of a Room object?
Like I already said: because you can set the record number (through a constructor I suppose) an API-user will also be able to change the record number (he just creates a copy of the instance with another record number).
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Sean Keane wrote:Ideally what I would like is to send a Room object to the client where they can't modify the record number and can't pass back a Room object that wasn't created on the server side.
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Roel De Nijs wrote:The problem will not be solved at all. What if you want to put all your transfer objects in a seperate package?
Roel De Nijs wrote:And I'm quiet sure that with using reflection I can easily invoke your protected setter (or just set the record number through the Field reference).
Roel De Nijs wrote:Or I can do easily something like this (no hacking, just a bit of OO):
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Sean Keane wrote:Plus I could make the class final to prevent it being subclassed.
Sean Keane wrote:Whereas the solution where you expose all the members as public conveys that it is OK and you support setting the record number in the client package when it is meaningless to do so and not your intention.
Roel De Nijs wrote:
Sean Keane wrote:Plus I could make the class final to prevent it being subclassed.
That would be the only possible (and working) solution, because I can easily put MyRoomTO in the same package as RoomTO.
Roel De Nijs wrote:
Sean Keane wrote:Whereas the solution where you expose all the members as public conveys that it is OK and you support setting the record number in the client package when it is meaningless to do so and not your intention.
That's simply what you get if you don't want to use getters/setters. And I prefer getting the cleaner code above taking some actions to prevent a record number from being set at the client (while because the record number is in the RoomTO object a developer will be able to set it with some extra code).
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Sean Keane wrote:If you have your business classes and client related classes separated out into separate packages then there's no need to make the Room class final.
A working solution in a single project setup is to put all business classes in the package suncertify.service.* and all client classes in a different package. Based on that setup there's no need for final.
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |