[bv-dev] Method Validation: Why Example 4.11 should be allowed

[Paul Benedict]

On Mon, Aug 27, 2012 at 9:49 AM, Emmanuel Bernard wrote:
> I think Gunnar explained that somewhere in this thread but here is the gist.
>
> There is a difference between what goes in (parameters) and what goes
> out (return values) of a method. As a client, if your subclass returns me
> a more constrained result that what was advertised that's ok, I can still
> work with it as I receive it.
>
> However when I pass parameter values to a method, things are different,
> if you make it more constrained, a parameter that is supposed to pass
> according to my contract does not pass if a subclass implementation happens to be used.

Emmanuel,

I don't see why you think there is substantial difference between the
two. I certainly don't see any. As a developer, I am either populating
POJOs for validation or calling service methods for validation. In
each case, failing validation prevents the normal flow of execution. I
can certainly make my POJO more constrained by subclassing it and
adding another constraint. A POJOs is just a delivery mechanism of
data .. as is a service method parameter.

Regarding "a parameter that is supposed to pass according to my
contract does not pass if a subclass implementation happens to be
used", as I have said in a previous email, that problem totally exists
today validating POJOs. We shouldn't treat this issue as a new issue.
If I am coding to class X but my provider has injected in Y (which
extends X and adds new constraints), I got the same problem. I am
going to fail validating that object.

Paul