commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <bali...@centras.lt>
Subject Re: [Lang] Validate
Date Wed, 23 Oct 2002 17:11:45 GMT
Hi,
It is trivial to code and I think we can to spend some time for naming.
I think :
1) "Check", "Validade" and "Validator" are "good" prefixes and sufixes for
methods and class names.
 2) "is" prefix is "bad" if method doe's  check and throws IAE, but it is
"good" if method returns boolean.

I prefer
ValidationUtils.check*( * arg )throws IllegalArgumentException;
OR
ValidationUtils.throwIf*( * arg )throws IllegalArgumentException;


From: <scolebourne@btopenworld.com>

> Are you volunteering to write this ;=) ??

Sure. Since

1) This has a very broad user base w/ lots of opinions and
2) I don't like to code in vain

...I'd just like an agreement on the initial public interface before I
proceed.

> Do we :
> 1) only deal with IAEs

Validate is IMO implicitely dealing with arguments in an object's methods.
State applies to the object as a whole. Such validation is more like
validating a correct argument in the wrong time. I cannot see how one can
validate state at the target object in a generic manner.

If it is a matter of validating the state of the object you pass as an
argument, I would say that an illegal state in that object makes that object
an illegal argument. ISE should be thrown if a method call brings the
_target object_ into an illegal state.

Or?

> 2) put IAEs and IStateE (ISEs) in the same class, thus prefixing each
method by argument and stateCheck

Ugh, no. But see below, there might be room for them existing in the same
class.

> 3) Name the classes ValidateArgument and ValidateState.

If there are possible generic utility methods for checking state, _perhaps_
a utility class containing them should be called "ValidateState" (the exact
name of the class depends a bit on the proposed name of the methods, the
whole method call must feel natural).

"Validate" validates the arguments of its method. I favor "Validate", and
leave the ValidateState for now. But if anyone has a suggestion for the
interface of the similar state validating utility, speak up now so that I
can write (and name) them in parallel. The easiest way of avoiding future
clashes: think beforehand.

If there are reasonable utility methods for checking state, I suspect that
their naming patterns would be so much different than the names for the
argument checking methods, so that they could live happily in a single
Validate class.

> For your interface, I would name the type method isInstanceOf, instead of
isOfType.

Hmm, yes, semantics would be that of the instanceof operator. I agree on
that.

> Yes, to basic String and Collection methods. No, to the number ones
(isTrue(i > 0) is just as easy).

Agree. What about the wrapper classes (Integer etc)?

The fact is that isTrue() _is_ easy for anything, so that apart from the
array checking methods and the null check, anything could be easily done
with isTrue(). For the object checking, you would only be missing the
implicit notNull() check (which is a compelling reason to keep those
methods).

> Yes, to having two versions of each method, one with a message and one
without. The one without could create a sensible error message.

Agree.

/O


--
To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message