Java Validation With Dynamic Proxies

By Eric Olson
2005-05-14


Tightly coupled validation
Throughout this article, I'll work with a simple User object that defines methods for dealing with a user in a system. Listing 1 presents the User interface and its methods.

Listing 1. User and its methods

/**

 * Gets the username of the User.

 */

String getUsername();



/**

 * Sets the username of the User.

 * @throws ValidationException indicates that validation of the proposed

 * username variable failed.  Contains information about what went wrong.

 */

void setUsername(String username) throws ValidationException;



/**

 * Gets the password of the User.

 */

String getPassword();



/**

 * Sets the password of the User.

 * @throws ValidationException indicates that validation of the proposed

 * password variable failed.  Contains information about what went wrong.

 */

void setPassword(String password) throws ValidationException;

In a tightly coupled data validation scheme, I would insert validation code directly into the interface's method implementations, as shown in Listing 2. Note that the validation logic is hardcoded into the method before the instance variable is set.

Listing 2. A tightly coupled validation scheme

public void setPassword(String password) throws ValidationException {

    if ((password == null) || (password.length() < MIN_PASSWORD_LENGTH)) {

        throw new ValidationException("INVALID_PASSWORD",

                                      "The password must be at least " +

                                      MIN_PASSWORD_LENGTH + 

                                      " characters long");

    }



    this.password = password;

}

In this example, the validation logic is tightly coupled to the object in which it's being used. The weaknesses of this approach should be fairly obvious:

* It doesn't introduce any reusable validation code. Although the example contains length and null checks that I could use in many other areas of the application, they're coded in such a way that they cannot be reused.

* The validation rules aren't configurable in any way. If I ever wanted to add another validation rule to the setPassword() method, for example, I would have to change the method itself, recompile, and possibly redeploy.

Although not ideal, tightly coupled validation code is quite common, particularly in older applications. Fortunately, tight coupling isn't the only option when it comes to coding the User interface's validation logic.

Tutorial Pages:
» Decouple validation processes from your business object implementations
» Tightly coupled validation
» Loosely coupled validation
» The dynamic proxy approach
» The invocation handler
» The business object implementation
» The business object factory
» Drawbacks of dynamic proxies
» Other uses for dynamic proxies
» Conclusion
» Resources


First published by

 |

Related Tutorials: » All about JAXP, Part 1 » Make Database Queries Without the Database » Load List Values for Improved Efficiency » 2 Ways To Implement Session Tracking » A Simple Way to Read an XML File in Java » Develop Aspect-Oriented Java Applications with Eclipse and AJDT