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

最新推荐文章于 2022-03-09 16:27:12 发布

iteye_14231

最新推荐文章于 2022-03-09 16:27:12 发布

阅读量97

点赞数

分类专栏：程序设计文章标签：网络应用设计模式应用服务器正则表达式软件测试

程序设计专栏收录该内容

8 篇文章 0 订阅

订阅专栏

对Web页面上的输入进行校验是我们必须的工作,既简单又繁琐.本文结合Visitor模式和反射,给出了一个该校验的一劳永逸的解决方案;即使你不想在你的实际应用中使用该方案,本文对我们应用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.printlns实现。这个方法也是使用反射达到目的的。

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属性记作 Integer1，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集团。

资源