Featured White Papers

• What Developers Want: The End of Application Redeploys

Sponsored Links

• Career opportunities at Harman- Careers That’ll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Validating value objects

Apply the Visitor pattern and reflection

By Sascha Frevel, JavaWorld.com, 06/14/04

In a business process, you often have attributes that must not be null and other attributes that could be optional. In the case of attributes that must be an instance, you have to implement a check similar to this:

if( attribute1 == null )
{
   throw new Attribute1IsNullException()
}

If the value object has N attributes, you will get something like this:

if( attribute1 == null )
{
   throw new Attribute1IsNullException()
}
if( attribute2 == null )
{
   throw new Attribute2IsNullException()
}
...
if( attribute N == null )
{
   throw new AttributeNIsNullException()
}

The result: A lot of if statements! And you have to type them all!

Now imagine that the number of validations increases from 10 to 25 because 15 new use cases must be implemented in the next iteration. Unnerving isn't it? An effective way to reduce these checks is to move all of them from the value object class into the value object's validating class.

At this point, you might recognize that you always perform the same checks. The only difference is the name and type of the attribute. In most cases, the type is not of interest because the compiler checks it. An important point is to be sure that the methods receiving the attribute's value all start with the same name. In our case above, this would be get.

Calling all the value object's getters by reflection is easy. If you use Eclipse, for example, you can generate the get/set methods for all attributes. So for our attribute1, the getter will be getAttribute1() and the setter, setAttribute1(Integer attributeValue), if attribute1 is an integer attribute. If these preconditions are given, you can think about a generic solution. This article explains how a generic solution could be realized using reflection and the Visitor pattern.

The framework's classes and interfaces

The following class diagram shows the relationships between the classes and interfaces used for building our generic validation framework.

Note: You can download these classes and interfaces from Resources.

Validateable interface

The Validateable interface complements the Visitable interface. The defined method validateWith() is the analog method to the accept() method in the Visitor pattern's Visitable interface. With the validateWith() method, you can validate the value object with different validators because this method takes an implementation of the IClassAttributeValidator interface as a parameter.

IClassAttributeValidator interface

The IClassAttributeValidator interface is the counterpart of the Visitor interface in the Visitor pattern. And its validate(AbstractParameter param) method is the counterpart of Visitor's visit(object SomeObject) method. The validate() method's AbstractParameter parameter type lets you access (validate) all parameters that are subtypes of the class AbstractParameter. In addition, using this interface in the validateWith() method as a parameter allows us to change the implementation of the used validator in the future for parameters that need a different validation—for example, testing the parameter attributes for a defined value range in addition to the null checks.