Did you end up playing with forMethod vs getMethodValidator ? I must admit, I'd like to see them in action before choosing.

What do others think. this is a decision between the following two approaches:

## Fluent approach

public interface Validator {

    MethodValidator<T> forMethod(Method method, T object);

    MethodValidator<T> forConstructor(Constructor<T> constructor);

}

public interface MethodValidator<T> {

    <T> Set<MethodConstraintViolation<T>> validateParameter(

        Object parameterValue, int parameterIndex, Class<?>... groups);

    <T> Set<MethodConstraintViolation<T>> validateAllParameters(

        Object[] parameterValues, Class<?>... groups);

    <T> Set<MethodConstraintViolation<T>> validateReturnValue(

        Object returnValue, Class<?>... groups);

}

## Getter approach

public interface Validator {

    MethodValidator getMethodValidator();

}

public interface MethodValidator<T> {

    <T> Set<MethodConstraintViolation<T>> validateMethodParameter(

        Method method, T object, Object parameterValue, int parameterIndex, Class<?>... groups);

    <T> Set<MethodConstraintViolation<T>> validateAllMethodParameters(

        Method method, T object, Object[] parameterValues, Class<?>... groups);

    <T> Set<MethodConstraintViolation<T>> validateMethodReturnValue(

        Method method, T object, Object returnValue, Class<?>... groups);

    <T> Set<MethodConstraintViolation<T>> validateConstructorParameter(

         Constructor<T> constructor, Object parameterValue, int parameterIndex, Class<?>... groups);

    <T> Set<MethodConstraintViolation<T>> validateAllConstructorParameters(

        Constructor<T> constructor, Object[] parameterValues, Class<?>... groups);

    <T> Set<MethodConstraintViolation<T>> validateConstructorReturnValue(

        Constructor<T> constructor, Object returnValue, Class<?>... groups);

}

## Comparison

The advantage of segregation is to avoid pollution of the main Validator interface especially if we add more methods in the future.

The getter approach has the benefit of being simple.

The fluent approach let's us factor the various methods between the methods and constructor calls and makes names less awkward. It also is consistent with some of the Bean Validation design using fluent APIs.
The drawback of of fluent API is that it requires two method calls for a validation:

• one to select the object and method

• one to validate the parameters / return value

It also creates a temporary object (returned by the first method).

I have captured this discussion at http://beanvalidation.org/proposals/BVAL-241/#validating

"DISCUSSION: Would a separate interface MethodValidator make sense?"

Emmanuel

On 1 août 2012, at 08:20, Gunnar Morling wrote:

Hi,

What do you other guys think?

I'll go and create a branch to play around a bit with a separate MethodValidator interface. Maybe it helps to have something more specific which we then can compare and discuss.

--Gunnar

Am 26.07.2012 10:38 schrieb "Hardy Ferentschik" <hardy@hibernate.org>:

On Jul 25, 2012, at 12:00 AM, Gunnar Morling wrote:

> Hi,
>
> 2012/7/23 Hardy Ferentschik <hardy@hibernate.org>:
>> Hi all,
>>
>> Let me pick up yet another TODO from the current spec.
>>
>> Section "5.1.2. Method-level validation methods" [1] still contains a TODO whether the methods for method validation should be hosted
>> on a different interface (other than javax.validation.Validator).
>>
>> At the moment all validation methods are hosted on javax.validation.Validator. Personally I don't see a strong reason for introducing
>> another indirection/interface. Does anyone have objections removing the todo?
>
> I guess Emmanuel does :)
>
> Personally, I also used to be of the opinion that a separate interface
> doesn't really add much value. What made me pondering though was the
> recent discussion about adding new bean validation methods such as
> validateProperty(T object, Path property, Class<?>... groups);
>
> Following the interface segregation principle [1], it may indeed be a
> good idea to have two separate interfaces, one for standard bean
> validation and one for method validation. I think the main question
> is, who the consumers of the individual methods are. I think there may
> be a broader range of users of the bean validation methods
> (validate(), validateProperty() etc.) than of the method validation
> methods (validateParameters() etc.), which typically will only be
> invoked by authors of integration/glue code. So for users of the first
> group it would reduce complexity if the method validation stuff went
> into a separate interface.
>
> With respect to retrieving method validators, instead of something
> like Validator#forMethod(Method method) etc. I could also imagine
> ValidatorFactory#getMethodValidator(). Then one doesn't have to
> retrieve a new validator for each validated method/constructor.

+1 for ValidatorFactory#getMethodValidator() in case we decide separate interfaces


--Hardy


_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev