"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,...
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.
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?
Sean Keane wrote:I hadn't stuck any in yet, but thanks for the tip about the record number :-)
Roel De Nijs wrote:I sometimes get the idea you are mixing up the assignment part and the create-an-api part
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
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".
Sean Keane wrote:I definitely got the impression that you were suggesting quite the opposite.