Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Where to put validating methods for POJOs?

 
Chengwei Lee
Ranch Hand
Posts: 884
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just wondering what's the best practices, or your prefered practices in keeping the validating methods for your POJOs? Should it be kept within the POJO or outside? Would it be better to leave the responsibility of passing in the right values to the calling client codes? Or should we have a separate validator class, then call the validating methods from inside the accessor methods? Or call in the calling client codes?

 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I like to see objects validate their own arguments. Trusting the client opens you to misuse and abuse by accidental or malicious incorrect clients.

Design By Contract
fans have rigorous techniques for validating arguments. Java Assertions come close to being a tool for this, but don't quite make it.

I'm lazy myself. If a null argument will cause a null pointer exception I'm more likely to just let it happen than to test for null and throw an invalid argument exception, unless I can give a really useful message to the user. For example, "You must select a file to delete" is a better message than a generic "Error deleting file" or "Null pointer exception" If I were shrink-wrapping a package for other developers I'd probably work harder to give the most informative exception possible.

You can externalize the validation rules to keep your method code clean and flexible. We pulled a validation component out of Struts and used it for a while, but it was pretty inconvenient for the value.
 
Chengwei Lee
Ranch Hand
Posts: 884
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I like to see objects validate their own arguments. Trusting the client opens you to misuse and abuse by accidental or malicious incorrect clients.


Agree with you obsolutely on this.

Design By Contract
fans have rigorous techniques for validating arguments. Java Assertions come close to being a tool for this, but don't quite make it.


Read from some article recently that with Java5, we could use annotations to self-validate POJOs. But then I'm still stuck with 1.4.

You can externalize the validation rules to keep your method code clean and flexible. We pulled a validation component out of Struts and used it for a while, but it was pretty inconvenient for the value.

Jakarta had taken out the validator component from Struts already right? So it could be more convenient to use now?

Thanks for sharing your experiences & thoughts.
 
Campbell Ritchie
Sheriff
Posts: 48917
58
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


Now, any method calling the forwardOneSecond method will be OK, because you can always move a clock forward one second. The set seconds method has a precondition, which is imposed on the caller, and a postcondition which is actually imposed on the Clock class.

Alternative:

Because there is a precondition and a postcondition which are the same, you can call that an invariant. Other invariants might be
  • Class Square: cornerList.count() == 4, side1 == side2.
  • Class Triangle: cornerList.count() == 3. No invariants about sides.

  • When the assertion mechanism came out there were complaints that it wasn't strong or rigorous enough, but I think it can be made rigorous by proper placing of precondition postcondition and invariant tests.
    Also, if you use "assert," you can turn it on with the -a flag in command prompt, otherwise the assertions are inactivated for a real-life run.

    CR
    [ June 20, 2006: Message edited by: Campbell Ritchie ]
     
    Campbell Ritchie
    Sheriff
    Posts: 48917
    58
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Throwing the IllegalArgumentException is consistent with design by contract; if you try to set the seconds to 61, the mistake is not in the Clock class, but the calling method, so it ought to be passed back there.

    A major principle of design by contract (which appears to be a trademark of the Eiffel language) is that each method has to sort out its own mistakes, not getting another method to sort out its mistakes.

    CR
     
    Chengwei Lee
    Ranch Hand
    Posts: 884
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks for the examples, sure makes things clearer for me.

    Just thinking that if my validation rules may change, this would mean code changes in my POJOs, so using the Jakarta Commons Validator, I would be able to make the changes in the XML file instead, so not much code changes, lesser risk of human errors? What do you think?
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic