Where to put validating methods for POJOs?

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?

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

posted Jun 19, 2006 20:00:00

0

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?

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: 41070

29

posted Jun 20, 2006 02:30:00

0

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

posted Jun 20, 2006 12:03:00

0

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?