aspose file tools*
The moose likes Beginning Java and the fly likes Where to put validating methods for POJOs? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Where to put validating methods for POJOs?" Watch "Where to put validating methods for POJOs?" New topic
Author

Where to put validating methods for POJOs?

Chengwei Lee
Ranch Hand

Joined: Apr 02, 2004
Posts: 884
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?



SCJP 1.4 * SCWCD 1.4 * SCBCD 1.3 * SCJA 1.0 * TOGAF 8
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Chengwei Lee
Ranch Hand

Joined: Apr 02, 2004
Posts: 884
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

Joined: Oct 13, 2005
Posts: 39834
    
  28


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

    Joined: Oct 13, 2005
    Posts: 39834
        
      28
    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

    Joined: Apr 02, 2004
    Posts: 884
    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?
     
     
    subject: Where to put validating methods for POJOs?