|
|
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
java.beans package to enforce data-validation rules. Unfortunately, the rest of us -- who are not in the business of crafting "reusable
software components that can be manipulated visually in a builder tool" -- quite often attempt to reinvent the wheel by abandoning
the core Java approach in favor of various proprietary solutions. The externalization of data-validation rules is the area
where you can see the most creativity. An interesting XML-based approach was recently proposed in the "Validation with Java and XML Schema" series of JavaWorld. While admiring XML technology, I believe that Java has everything needed to solve the issue in the most elegant way. To
show you, I invite you to rediscover some of the real gems found in the java.beans package. They will help you build a few useful classes and learn a couple of interesting tricks.The logic behind constrained properties in Java is quite simple. Before accepting a new data value, the object (owner of the
constrained property) makes sure it is accepted by all interested parties that may veto it. Such a "request for approval"
is delivered to every registered java.beans.VetoableChangeListener in the form of a java.beans.PropertyChangeEvent object. If one or more vetoes have been issued, the proposed data value is rejected. A veto is presented by a java.beans.PropertyVetoException. Generally speaking, the complexity of the rules enforced by those listeners has no limit and depends only on the project's
requirements and the developer's creativity. The objective of this exercise is to learn how to deal with the most generic
data-validation criteria that you can apply to most objects.
First, let's create a class called BusinessObject with a simple numeric property. Next, I'll show how you can modify the property into a constrained one to see how it differs
from the simple one.
public class BusinessObject {
private int numericValue;
public void setNumericValue(int newNumericValue) {
numericValue = newNumericValue;
}
public int getNumericValue() {
return numericValue;
}
}
Please note that the only property of this class will silently accept any value of the proper type. To make it constrained,
a vetoable event needs to be produced and distributed to the consumers. A utility class called java.beans.VetoableChangeSupport was designed specifically to fulfill this set of responsibilities. A new class called ConstrainedObject will manage all the arrangements with this utility class, thereby being a good loving parent for the BusinessObject. Speaking of consumers, we need to build another custom class called Validator that hosts generic data-validation algorithms. It is going to be the only consumer of the vetoable events in our framework.
This simplified approach deviates from the rules of the JavaBeans game (check JavaBeans API Specification for details), which requires presenting every constrained property as a bound one and providing support for handling multiple
listeners. This deviation is perfectly acceptable, since you are not building a JavaBean here, but it's still worth mentioning.
java.beans package