Where to put validating methods for POJOs?

[Chengwei Lee]

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]

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]

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]

public class clock
{
   private int hour, minute, second;
   public static final int SECONDS_IN_MINUTE = 60, MINUTES_IN_HOUR = 60, HOURS_IN_DAY = 24;
. . .
 
   public void forwardOneSecond()
   {
       second++;
       second %= SECONDS_IN_MINUTE;
       if (second == 0)
           forwardOneMinute();
   }// No particular validation necessary
 
   public void setSecond(int second) throws AssertionException
   {
       assert (second >= 0 && second < SECONDS_IN_MINUTE);//precondition
       this.second = second;
       assert (this.second >= 0 && this.second < SECONDS_IN_MINUTE);//postcondition
   }// validation necessary
. . .
}// end class

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:

   public void setSecond(int second) throws IllegalArgumentException
   {
       assert (this.second >= 0 && this.second < SECONDS_IN_MINUTE);//invariant
       if(second < 0 || second >= SECONDS_IN_MINUTE) throw new IllegalArgumentException();
       try
       {
          this.second = second;
          assert (this.second >= 0 && this.second < SECONDS_IN_MINUTE);//invariant and postcondition
       }
       catch(Exception e)
       {
          //Some sort of logging of the error for correction.
          //You have actually reset the second to what it was before.
       }
   }// validation necessary   

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]

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]

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?