Handling Null & Empty String in your Tranfer Object

[Sean Keane]

For anyone that used a transfer object to send information between the client and business service, how did you handle the fact that a String could be set to either null or the empty string?

For example, take the owner field of the Room transfer object - when you sent this to the client what indicated that the room owner was not set? The fact that the field was null or the empty string, or both values were allowed i.e. both values indicated that a room owner was not set?

My transfer object is not just using Strings. It is using other data types too. So Date for date member, int for the size, boolean for smoking.

Also, at which point did you validate the room record to ensure it did not contain invalid data e.g. null for a date, or a field being too long?

- In your Business Service, when the Room transfer object is received at the Business Service from the client?
- In your Business Service, when the Room transfer object is being converted into an array to be passed on to your Data class?
- In methods of your Data class? (Or methods called by your Data class to write the record to the file\cache.)

I guess all validation could be deferred until the String[] record is passed into methods from your Data class?

For methods in your Data class that received a String[] array did you expect all values of the String[] array to be non-null entries, and an empty string indicated that a field is not set?

[Roel De Nijs]

I perform validation in the Data class: each String[] is validated against the database schema and null-values are only allowed when calling the find-method.

In the business validation I only perform business rule validations and the only business rule I could find, is the one about the customer id and that's the only one I checked in my business service.

[Sean Keane]

It does seem like a cleaner approach to simply defer any failure due to invalid data until we get to the Data class and it's the simplest option. Does anyone know if that is typically how things would normally be set up in say the J2EE world?

I usually prefer to go with the approach of:

1) Preventing failure - prevent client code passing invalid data to server.
2) Fail as early as possible.
3) Fail as near to the cause of the problem as possible.

So I was thinking of preventing my transfer object to allow nulls be set for any fields. However this is getting messy on me, so needs a rethink. I'm basically doing a subset of validation at the client side, then preforming the rest of the validation on the server side.

One side of me is thinking to stick with my points above as a guideline, another side of me is saying it's ok to let the client code set anything it wants in the transfer object and it's ok to let this pass through the business layer, and only fail when we hit the data class. Hmmm.

[Roel De Nijs]

It's ok to have validation at the client side, but you should always have the same validations at the server-side, because your server should be protected completely. Because your server could be used from another client which does not have these validations and that would be no good.

Where you put the checks depends on what you are validating. In a business service you'll validate the business rules. So if a customer id must be a 8 digit number, that's something I validated in my business service. The update of the record will never happen if the customer id is not a 8 digit number (of course this runtime exception will never be thrown in the application, because this business rule is forced in the GUI too). As far as I can remember this is the only business rule (together with the minor 48-hours rule), but if name and location together must be shorter than 80 characters, that would be something I check in my business service validations. Or if we would have an updateRoom-method the length of each field would be validated in the business service too (although it might never occur because the GUI makes it impossible to enter a location which has more characters then allowed).

In my Data class I don't really do actual validations, I just check if the provided String[] has the expected format, so in the actual code of my update-method I can just put the needed logic and don't have to clutter the code with a lot of checks (e.g. array is null, size array, value not too long,...). If the format is not the expected one, a runtime exception is thrown. This exception should not be handled in the program, because it indicates a developer mistake (and in its description gives the developer a bit information about what's wrong).

[Sean Keane]

I was just looking through the code from Andrews book and he does no validation at all that I could see at the server side. I haven't tried running it by sending null's in the transfer object, but from a quick glance at the code it looks like it would just blow up with a null point exception.

Server side validations - definitely agree that these need to be there. I have them all in a separate class which I make a call out to in my update & create methods. Here I check things like:

- Correct number of fields (i.e. array is correct size)
- Check for nulls.
- Check field lengths are correct.
- Check field contents are correct e.g. if a field is meant to have a number, can the string be parsed to a number? if it is meant to have a certain value, e.g. Y or N

Roel De Nijs wrote:In my Data class I don't really do actual validations, I just check if the provided String[] has the expected format, so in the actual code of my update-method I can just put the needed logic and don't have to clutter the code with a lot of checks (e.g. array is null, size array, value not too long,...

So where do you have all this "clutter" with the checks? Do you have them in a separate class and you call that from the update-method? Or is that validation carried out before the String[] array is passed to the update method?


Business validations - I hadn't stuck any in yet, but thanks for the tip about the record number :-)

Client validations - I haven't gotten around to my client yet. But as you suggested Roel, I will be coding it so that you can't enter invalid data.

The main bit I'm pondering at the moment is how much checking I should put in place to ensure that it's not possible to send invalid information to server or business layers from the client. For example I could ensure that my transfer object will do things like preventing nulls to be set to string\object fields.

On the one hand, I am thinking it's good to add checks to the transfer object because it will help me meet these guidelines

1) Preventing failure - prevent client code passing invalid data to server.
2) Fail as early as possible.
3) Fail as near to the cause of the problem as possible.

But on the other hand, I don't want to replicate my server checks on the client side - duplication of code, carrying out the same operation twice etc. So then I am asking myself "is there any real benefit in adding a sub-set of the checks to the transfer object - just let the invalid data hit the server and handle it there".

For example, preventing null's being set in the transfer object - it will stop nulls hitting the server. But the string content could still be invalid. So it's sort of a half-way-house solution.

[Roel De Nijs]

I sometimes get the idea you are mixing up the assignment part and the create-an-api part (e.g. your remark about code in Andrew's book: putting null in the transfer object blows the thing up, I'll comment on that one further down in this post). These are completely other things.

You (always) have to make a distinction between what's needed for
a) the assignment
b) creating a developer-friendly API which can be used by other developers

For a) you don't need much: some client side validation to ensure a correct port number for the server and a correct customer id. And that's really all you need, because the user can't do much more. So you can develop your complete code with almost no validations (like in Andrew's book). You really don't need more, because you develop the application and you'll make sure you don't pass a wrong String[] to the update-method for example.

For b) you need a whole lot more, because you want to give a developer who is using your API some guidance when he makes a mistake in using your API. So you add some checks in your Data class, e.g. when a method is called before calling the init-method, when he passes a String[] with not enoguh elements, when he calls lock-method 2 times,... Each time the developer wrongly uses the API he will get some IllegalXxxException with a little description about what to do. These exceptions are not meant to be caught, because they are only thrown when a developer makes a mistake (and that should not happen anymore when the application is released) and the user of the application will not be able to do something to solve the issue (except waiting for a next release with a bug fix).
And of course you as API designer and developer decides how far you are willing to take this extra work. But I myself hate an API which throws a NullPointerException and I have to take a look at the source code (or even decompile the class file) to get an idea why I got this unexpected exception. Therefor I put a lot of effort in making my API as developer-friendly as possible. This should also make it easier for a junior programmer to make changes to your code. But that's not something which is required by the assignment.

That's just my view on things and sometimes people have difficulties in making the distinction between these 2 parts.

Sean Keane wrote:I was just looking through the code from Andrews book and he does no validation at all that I could see at the server side. I haven't tried running it by sending null's in the transfer object, but from a quick glance at the code it looks like it would just blow up with a null point exception.

From the assignment point of view that's not a problem at all. Because he was the developer, so he knew passing nulls in the transfer object is not a good idea and he didn't do it when developing the application. When a user left the input field empty, he passed an empty string to the transfer object. If of course he made a developer mistake and passes a null to the transfer object, the application might crash during assessment which is not a good thing From the API point of view that's a poor API, because you'll get a NPE and you don't know why. But let us assume he made his API more developer-friendly throwing an IllegalArgumentException when you set null in the transfer object. When he makes the developer mistake again in this situation, the application might crash during assessment (with another exception of course), but it's still not a good thing and will affect your score So although he added some validations, the program still blew up because he made a developer mistake (and didn't test his application enough)

Sean Keane wrote:So where do you have all this "clutter" with the checks? Do you have them in a separate class and you call that from the update-method? Or is that validation carried out before the String[] array is passed to the update method?

Nothing to fancy: just a seperate private method in Data class, which is called from other methods

Sean Keane wrote:I hadn't stuck any in yet, but thanks for the tip about the record number :-)

It's the customer id

[Sean Keane]

Roel De Nijs wrote:I sometimes get the idea you are mixing up the assignment part and the create-an-api part

I don't think I am mixing up the two, but let me get to that below . I think I see the direction you are coming from. Basically that I am the only person who will ever use the code that I write. That I am not designing an API. So it is sufficient to have an application that works, is designed well, is well tested, and well documented - this will get you passing the assignment and maybe even a perfect score! This is all probably true.

However, when it comes to programming in general I wouldn't make the distinction between developing and API design. I would generally always try to approach it from the view point of designing an API as it ends up giving you more sensible, easy to understand, and robust code. I always ask myself these type of questions:

* How easy would it be for someone to understand this code without reading any documentation.
* How hard is it for someone to make my code blow up.
* How intuitive is my code.

I was happy recently to view a video from Joshua Bloch that preached the exact same message in a talk about API design. One of the very first things he says in his speech is that "Anyone that programs a computer is an API designer" followed by "thinking in terms of API tends to improve the quality of the code you write".

Here is an extract from one of his slides that people may find interesting

Characteristics of a Good API

* Easy to learn.
* Easy to use, even without documentation
* Hard to misuse
* Easy to read and maintain code that uses it

I think the moral of the story is that yes you can quite easily approach this assignment from the view point of not developing an API and probably even get a perfect score. But as a general rule, approaching developing as if you are developing an API is a very good approach with quite obvious benefits.

So it's not that I have a problem distinguishing between the assignment versus API design. That is a conscious decision I make to approaching design and development. Hopefully I have highlighted why this is a beneficial approach as a general rule for programming and design - and not just my idea but an approach championed by quite a prominent software and API designer.

[Roel De Nijs]

Sean Keane wrote:I don't think I am mixing up the two

Sean Keane wrote:I was happy recently to view a video from Joshua Bloch that preached the exact same message in a talk about API design. One of the very first things he says in his speech is that "Anyone that programs a computer is an API designer" followed by "thinking in terms of API tends to improve the quality of the code you write".

That's of course all true, he knows what he is talking about

The point I was trying to make, clearly not a success Andrew's book is dedicated to this assignment, covering all aspects of this assignment (rmi, sockets, gui,...). And i assume that's the reason why e.g. validation in the Data class lacks, because it's not important for the assignment. Explaining the key concepts you need for the certification is the purpose of the book (and probably there was also a maximum number of pages limit to do it ). I was certainly not trying to convince you to do nothing more but a few client-side validations and submit the assignment.
On the side: I doubt if just doing this stuff would result in a perfect score, simply because I think you'll lose points in "general considerations" because your code would be harder to use and maintain.

[Sean Keane]

Ah, ok, I was just throwing Andrews solution out there as another solution to add to the discussion. Not to criticise or anything.

That's quite a good talk by Joshua Bloch. Maybe I picked you up wrong, I definitely got the impression that you were suggesting quite the opposite. But it sounds like we are saying the same thing so, that thinking in terms of API design when designing\developing is a good approach to follow

[Roel De Nijs]

Sean Keane wrote:I definitely got the impression that you were suggesting quite the opposite.

No need to worry I always try to pursue the characteristics of good API design. I did that already when working as a perm in an IT team and now as a consultant you must follow these standards, because you create code which will be used by some other developers and when the project ends you as a consultant are gone, but these guys (and girls) still have to maintain and extend this code.