Sure - For example the LaguerreSolver has the following set of lines in the
start of the solveAll method:
if (coefficients == null) {
throw new NullArgumentException();
}
int n = coefficients.length - 1;
if (n == 0) {
throw new NoDataException(LocalizedFormats.POLYNOMIAL);
}
Move these to a Validator class (Could be an inner class of the LaguerreSolver)
that has a validateSolveAll method in it:
public void validateSolveAll(Complex coefficients[], Complex initial)
{
if (coefficients == null) {
throw new NullArgumentException();
}
int n = coefficients.length - 1;
if (n == 0) {
throw new NoDataException(LocalizedFormats.POLYNOMIAL);
}
}
Now if you are the client you would do:
validateSolveAll(..)
solveAll(..)
If you are a user interface designer you would wrap the validateSolveAll in a
validator for the user interface framework being used to provide real time
feedback to the user. It makes life easier for the GUI Designer because the
validation exceptions have been separated from other types of exceptions, like
a ConvergenceException.
Cheers,
- Ole
On 03/04/2011 05:32 PM, Gilles Sadowski wrote:
Hi.
Just want to throw another idea into the mix. How about stripping all the
validation argument validation lines and putting in separate validator classes.
Clients would call the validator on the arguments for the class before passing
the arguments to the class's method. It makes the core classes more focused
and efficient and enables clients to wrap method invocations with aspects that
apply the validation routine.
Could you post a little code example?
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
