commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: svn commit: r1042596 - in /commons/proper/math/trunk/src/main/java/org/apache/commons/math: analysis/solvers/ distribution/
Date Tue, 07 Dec 2010 09:47:20 GMT

> > [...]
> > 
> > I think that we can satisfy this use-case without exposing the variables:
> > 
> > ---CUT---
> >> BrentSolver mySolver = new BrentSolver();
> >>
> >> // initialize GUI
> >> solverGui.setRelAccuracy(mySolver.getRelativeAccuracy());
> >> solverGui.setAbsAccuracy(mySolver.getAbsoluteAccuracy());
> >>
> >> // fire the GUI
> >> ...
> >>
> >> // in the action callback from the GUI OK button, create the solver
> >> double rel = solverGui.getRelAccuracy();
> >> double abs = solverGui.getAbsAccuracy();
> >>
> >> mySolver = new BrentSolver(rel, abs);
> > ---CUT---
> Creating two solvers to use only one and simply hiding constants seems
> awkward to me. Just letting the constants visible is simpler.

You don't use only one. And, arguably, for the GUI, the first solver
instance is the most important because it provides the needed information.

What bothers me most with the variables is:
 1. The redundancy:
      The value is stored once in the static variable of the class and a
      second time in each instance.
 2. The possible inconsistency:
      Nothing prevents a (sub)class to *not* use the default. So the
      documentation could be misleading whereas the accessor will always
      provide the actual value.

GUIs _are_ awkward. Having to create two solvers in such a context is
negligible and a very small price to pay for ensuring consistency.

> I think what Sebb pointed out in this issue was not that the constants
> were public, but that these constants were duplicated. I agree with him
> here. However solving the issue by removing the duplication and having
> constants defined in the top level interface is more straightforward.

There are 2 problems with this:
 1. The top-level class where such "public" constants should be defined is
    "BaseAbstractUnivariateRealSolver". This is not a "user" class but a
    "developer" class, an implementation detail. Encouraging users to have
    that class appear in their code is not good design.
 2. The "accuracies" might mean different things for different solvers and
    thus the defaults might be set to different values depending on the
    implementation. [That is why I had created a static variable for each

Please note also that by using the accessor, users can code through
interface while with the static constant, their code must reference a
concrete class.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message