-1

Every time I've seen this attempted in other projects I've worked on,
it ends up making things dirtier rather than cleaner.  That utility
class ends up with 100 methods, a third of which end up not being used
any more but no longer maintained...  blech.

-T

On Fri, Apr 17, 2009 at 5:34 AM, Sandro Martini
<[email protected]> wrote:
> Hi to all,
> following the discussion on this
> https://issues.apache.org/jira/browse/PIVOT-98 , i remember that in
> some my projects i developed some utility classes that make generic
> (but common) checks on values, without having to repeat the same check
> many times and in many sources.
>
> For example, instead of write (pseudo-code):
>
> if (opacity < 0.0f || opacity > 1.0f)
>    throw new IllegalArgumentException("opacity must be in the range
> [0.0 .. 1.0]");
>
> and the same for ranges [0..255], for empty or null Strings, null
> arguments, etc.
>
> using this approach we could call something like this (from a
> dedicated utility class, or maybe some specialized versions, by
> context):
>
>        public static final boolean checkRange(double value, double min,
> double max, String errorMsg, boolean exceptionOnValidationFailure)
>        public static final boolean isValueInRange(int value, int min, int
> max, String errorMsg)
>        public static final boolean isValueInRange(double value, double min,
> double max, String errorMsg)
>
>        public static final boolean checkName(String name, String errorMsg,
> boolean exceptionOnValidationFailure)
>        public static final boolean isNameNotEmpty(String name, String 
> errorMsg)
>
>        public static final boolean checkNotNullObject(Object obj, String
> errorMsg, CodeManager codeManager, boolean exceptionOnNull)
>        public static final boolean isObjectNotNull(Object obj, String 
> errorMsg)
>        public static final boolean isObjectStorable(Object obj, String 
> errorMsg)
>
> etc ...
>
>
> and the same for notNull, range checks, not Serializable, etc
>
> Where all checkXxx methods could throw RuntimeException or some Pivot
> derived class.
> And also methods like isXxx that only returns true or false.
>
>
> Or maybe use / extend the Validation classes already in Pivot ...
>
>
> What do you think ?
>
> Thanks,
> Sandro
>

Reply via email to