校验值对象——应用Visitor模式和反射

                                                                         校验值对象                                                                  ——应用Visitor模式和反射                                                                    作者：Sascha Frevel 概要值对象是一些单一的参数，用来联合一系列的对象——在大多数的情况下，在一个方法调用里有各种各样的参数。这些参数描述了一个大数量级的属性，通常，这些属性需要单独检测，而且大多数情况下是检测其是否为null。通常，这些检测带出来了大量的代码行。这篇文章描述了如何实现基于著名的Visitor模式和反射的值对象。 在业务过程中，你通常有一些属性不能为空，而另外一些则没有这样的要求。在那些必须有实例的属性的案例中，你不得不实现如下所示的检测：if( attribute1 == null )
{
     throw new Attribute1IsNullException()
}如果值对象有N个属性，你将会得到如下所示的代码：if( attribute1 == null )
{
      throw new Attribute1IsNullException()
}
if( attribute2 == null )
{
      throw new Attribute2IsNullException()
}
...
if( attribute N == null )
{
      throw new AttributeNIsNullException()
}结果：一大堆的IF语句，但是你不得不把它们全部打出来。现在假设校验的数量从10增加到25，因为有15个新增的用例必须在一个循环中实现。你是不是失去了勇气？用来减少这些检测的一个有效的方法是将他们从值对象类移到值对象的校验类。从这个观点看来，你可能承认你永远执行相同的检测。唯一的不同是属性的名称和类型。在大多数情况下，类型不让人感兴趣，因为由编译器检测它。还有重要的一点需要确认：接收这些属性的值的方法都由同一个名称开始，在我们的案例中，是get。通过反射调用这些值对象的getters方法非常简单。如果你使用Eclipse，例如，你可以自动为所有的属性产品setters和getters方法。对于我们的

attribute1

，getter方法是

getAttribute1()

，setter方法为

setAttribute1(Integer attributeValue)

。如果

attribute1

是Integer类型的属性。如果这些前提给定了的话，你就能考虑一个一般的解决方案。这篇文章解释了如何使用Visitor模式和反射来实现这个一般的解决方案。 框架类和接口下面的类图显示了建立我们一般的校验框架需要用到的类和接口之间的关系：

注意：你可以从Resources上下载这些类和接口 Validateable接口

Validateable

接口有着和

Visitable

接口相同的功能。那个定义的方法

validateWith()

是一个和Visitor模式里的Visitable接口的

accept()

方法相似的方法。通过

validateWith()

方法，你就能够校验有着不同validators的值对象，因为这个方法以

IClassAttributeValidator

接口的实现作为参数。 IClassAttributeValidator接口

IClassAttributeValidator

接口和Visitor模式的Visitor接口相对应。其中的

validate(AbstractParameter param)

方法和Visitor接口的

visit(object SomeObject)

方法相似。

validate()

方法的

AbstractParameter

参数类型允许我们通过任何

AbstractParameter

类的子类类型的参数访问validate。另外，在

validateWith()

方法里使用这个接口作为参数允许我们在将来改变使用的validator，用这些改变的validator作为来满足不同的validation的需求——例如，除了null检测以外，在一个定义的值范围测试参数属性。 AbstractParameter

AbstractParameter

类实现了

Validateable

接口的

validateWith()

方法。就像你将要看到的下面的代码片断一样，这个实现非常简单。这个方法仅仅是调用给定的validator的

validate()

方法，并且传递参数对象到validator：public void validateWith( IClassAttributeValidator validator ) throws Exception
{
      validator.validate( this );
}而且，

AbstractParameter

也实现一些常用的其他方法。受保护的方法：

addOptionalMethod()

使得所有的子类型增加一些可选择的方法到

optionalGetAttributeMethods HashMap()

。继承自

AbstractParameter

使得你能够取得哪些可能传递null的getters方法。就像你能想象到的一样，你能够增加可选择的方法，例如，到继承自

AbstractParameter

的值对象的构造器里。

isOptionalMethod()

方法用于检测属性是否已经被校验过了。

toString()

方法实现了一些便利，因为值对象可能是由很多属性组成。使得在

AbstractParameter

的子类里，不需要写很多的

System.out.println

s实现。这个方法也是使用反射达到目的的。 GenericClassAttributeValidator

GenericClassAttributeValidator

类实现了

IClassAttributeValidator

接口的

validate()

方法。这个类同时也实现了单态模式。

validate()

的实现看起来象下面这样：public synchronized void validate( AbstractParameter param ) throws AttributeValidatorException
{
      Class clazz = param.getClass();
      Method[] methods = clazz.getMethods();

      //Cycle over all methods and call the getters!
      //Check if the getter result is null.
      //If result is null throw AttributeValidatorException.
      Iterator methodIter = Arrays.asList( methods ).iterator();
      Method method = null;
      String methodName = null;

      while ( methodIter.hasNext() )
      {
            method = (Method) methodIter.next();
            methodName = method.getName();

            if ( methodName.startsWith( "get" ) &&
            clazz.equals( method.getDeclaringClass() ) &&
                 !param.isOptionalMethod( methodName ) )
            {
                 Object methodResult = null;

                 try
                 {
                       methodResult = method.invoke( param, null );
                 }
                 catch ( IllegalArgumentException e )
                 {
                       throw new AttributeValidatorException( e.getMessage() );
                 }
                 catch ( IllegalAccessException e )
                 {
                       throw new AttributeValidatorException( e.getMessage() );
                 }
                 catch ( InvocationTargetException e )                 {
                       throw new AttributeValidatorException( e.getMessage() );
                 }

                 if ( methodResult == null )
                 {
                       String attributeName = methodName.substring( 3, 4 ).toLowerCase() +
                       methodName.substring( 4, methodName.length() );
                       String className = clazz.getName();
                       className = className.substring( className.lastIndexOf( '.' ) + 1 );

                       Integer errorNumber = new Integer( 1000 );
                       throw new AttributeValidatorException( "Error: " + errorNumber + " "
                       + attributeName + " in " + className +" is null!!!");
                 }
            }
      }
}首先，就像你在代码里看到的那样，我们从值对象里取得所有的方法。然后，我们遍历所有方法的集合。如果方法以get开头，便是

AbstractParameter

的子类型，而不是可选择的方法。我们通过反射调用getter方法，并且检测它的结果。如果结果是null，那么这就是一个错误；如果不是，便是正常情况。那些可选择的方法和继承自父类的方法不会被执行。 测试我们的类现在，我们实现了我们所需要的所有的类和接口。我们必须做一些测试来检验我们的类是否能够正常工作。为了做到这一点，我们写了一点小的测试类和一个main方法来运行测试。 TestParameter

TestParameter

类继承自

AbstractParameter

，并且包括了一些需要校验的私有属性：很简单的4个Integer属性。 Optional attributes为了识别可选的属性没有被检测，我们定义了为属性：

testParam3

可选的getter方法。为了这个目的，我们通过

TestParameter

的构造器里的

addOptionalMethod(methodName)

方法将这个getter方法输入到父类

AbstractParameter

的可选方法map里。 校验框架是如何工作的为了测试，我们在

TestParameter

里使用如下方式输入：TestParameter param = new TestParameter( );
param.setTestParam1( new Integer( 1 ) );
param.setTestParam2( new Integer( 2 ) );
param.setTestParam3( new Integer( 3 ) );
param.setTestParam4( new Integer( 4 ) );就像你所看到的那样，4个

Integer

属性记作

Integer

1，2，3和4。为了校验，我们仅仅调用：param.validateWith( GenericClassAttributeValidator.getInstance( ) );这个校验的结果是：testParam1: 1
testParam2: 2
testParam4: 4

testParam3

属性没有被校验，因为我们记录了它的getter方法为可选的。其他所有的方法得到了校验，并且结果是正常的。现在，我们希望看到其中的一个属性值为空，这样我们就能检测是否validator能够检测到这个错误。我们注释掉下面的行：param.setTestParam2( new Integer( 2 ) );我们重新开始测试以后，得到如下的结果：testParam1: 1
Error: testParam2 in TestParameter is null!!!
testParam4: 4现在我们看到了validator已经检测到了这个没有赋值的属性。 如果属性类型为集合类型，将会怎么样呢？如果属性类型为集合，它仍然会检测这个集合是否为空。但是，可能检测集合是否为null并不是你想要的。在大多数情况下，你希望检测集合里的对象是否为null。如果集合的实现不允许null对象，你不需要关心这些在

GenericClassAttributeValidator

里的null对象继承自

AbstractParameter

。一些为集合保持继承自

AbstractParameter

的对象的辅助代码看起来如下所示：if ( methodResult instanceof Collection )
{
      Collection col = (Collection) methodResult;
      Iterator iter = col.iterator();
      Object subParam = null;

      while ( iter.hasNext() )
      {
            subParam = iter.next();

            if ( subParam instanceof AbstractParameter )
            {
                 AbstractParameter abstractParam = ( AbstractParameter ) subParam;
                 abstractParam.validateWith( this );
            }
      }
}集合里的所有没有继承自

AbstractParameter

类的对象没有被检测，因为我们将使用一个不允许null对象的集合实现。所以集合实现为我们完成了检测。如果你决定使用一个允许null对象的实现，那么为while循环的所有其他的对象的一个额外的null检测就是必须的了：else if( subParam == null )
{
      System.out.println( "Error: SubParameter not set in Collection!" );
} 值之间的依赖在一些情况下，只有当值对象的其他属性被分配了值，一个属性才有可能是可选的。属性的“可选性”

sometimesOptional

依赖于

actionType

属性的值。可能

action

属性持有的值代表了actions：例如

addSomething

=

1

,

updateSomething

=

2

, 和

deleteSomthing

=

3

。如果

action

的值是1或者3，

sometimesOptional

属性不是可选的；如果action的值是2，则是可选的。当我们为

actionType

赋值的时候，我们必须设置

sometimesOptional

的可选性：public void setActionType(int actionType)
{
      this.actionType = actionType;
      super.clearOptionalMethods( );
      switch( this.actionType )
      {
            case ActionParameter.ACTION_ADD :
            super.addOptionalMethod( "getSometimesOptional4" );
            super.addOptionalMethod( "getSometimesOptional5" );
            break;
            case ActionParameter.ACTION_UPDATE :
            super.addOptionalMethod( "getSometimesOptional1" );
            break;
            case ActionParameter.ACTION_REMOVE :
            super.addOptionalMethod( "getSometimesOptional1" );
            super.addOptionalMethod( "getSometimesOptional2" );
            super.addOptionalMethod( "getSometimesOptional3" );
            break;
            default :
            break;
      }
}你会看到清除可选方法列表是必需的，因为如果你给

actionType

赋值超过一次的话，越来越多的方法将作为可选的方法添加进来。另外的一个解决方法包括实现一个

AddActionParameter

，一个

UpdateActionParameter

和一个

RemoveActionParameter

，它们都是从

AbstractParameter

类继承得来。那么你可能不需要

actionType

属性。但是拥有

actionType

属性的类存在并且经常被使用，对该类使用反射非常容易，你必须使用Switch语句。 展望现在，我们可以考虑继承

AbstractParameter

的更多的功能——例如，范围校验。

AbstractParamter

需要一个数据结构来存储范围值。

HashMap

能够做到，它以方法名作为key存储范围对象。或者你可以检测是否一个String类型的值包含一些定义的字。等等。你也可以考虑Perl 5的正则表达式。所有的这些检测都可以在

Validator

类里实现，它实现了

IClassAttributeValidator

接口。如果你想使用属性的null检测和附加值检测，那么你可以写一个子类来继承

GenericClassAttributeValidator

。在J2EE应用里，值对象经常被用来在客户端和服务器之间传递业务过程的数据。但是，如果你仅仅在服务器端校验这些值对象的属性，你常常不得不因为一个错误的非可选属性为null而取消业务过程。你必须中断业务过程，而向客户端发送一个错误页面。这是一个好的实践：在服务端应用这些validators的同时，你也可以以委派的形式在客户端应用它们。在客户端检测值对象可以避免不必要的对服务器的请求和降低网络堵塞。 写一次，使用多次如果你使用我描述的方法来检测你的值对象的属性，你可以永远只增加值对象的属性——不用改变validator，它们能够被自动检测是否为null。你也可以不用改变validator而改变一个属性的条件。而且，当然，一个已有的validator也能够校验一个未来的值对象，如果这个值对象继承

AbstractParameter

的话。还有，你也可以不用改变值对象而写一个额外的validators，因为validators实现的是Visitor模式。这就是所谓的写一次，使用多次。 关于作者Sascha Frevel在德国的Zweibrücken的the University of Applied Sciences学习计算机科学。他自从1998年以来使用Java编程。自从2001以来，他的主要兴趣在于J2EE的应用设计和开发。他现在的工作身份是the software subsidiary company of ProsiebenSat1 Media AG的Java/J2EE开发人员和技术经理、软件架构师，这是德国的一家最大的corporate TV集团。 资源 Download the source code that accompanies this article:
http://www.javaworld.com/javaworld/jw-06-2004/validate/jw-0614-validate.zip
Design Patterns, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (Addison-Wesley, January 1995; ISBN: 0201633612):
http://www.amazon.com/exec/obidos/ASIN/0201633612/javaworld
Core J2EE Patterns, Deepak Alur, Dan Malks, John Crupi (Prentice Hall PTR, June 2003: ISBN: 0131422464):
http://www.amazon.com/exec/obidos/ASIN/0131422464/javaworld
J2EE Patterns, Adam Bien (Addison-Wesley, February 2002; ISBN: 382731903X):
http://www.amazon.de/exec/obidos/ASIN/382731903X/javaworld
"Java Tip 98: Reflect on the Visitor Design Pattern," Jeremy Blosser (JavaWorld):
http://www.javaworld.com/javatips/jw-javatip98.html
For more on design patterns, please browse these JavaWorld resources:
The Design Patterns section of our Topical Index:
http://www.javaworld.com/channel_content/jw-patterns-index.shtml
David Geary's Java Design Patterns column:
http://www.javaworld.com/columns/jw-java-design-patterns-index.shtml
Browse the Development Tools section of JavaWorld's Topical Index:
http://www.javaworld.com/channel_content/jw-tools-index.shtml