On 17 August 2012 12:15, Gilles Sadowski <gil...@harfang.homelinux.org> wrote: > On Fri, Aug 17, 2012 at 11:46:22AM +0100, sebb wrote: >> On 17 August 2012 11:24, Gilles Sadowski <gil...@harfang.homelinux.org> >> wrote: >> > On Fri, Aug 17, 2012 at 09:40:49AM +0100, sebb wrote: >> >> On 17 August 2012 07:40, Luc Maisonobe <luc.maison...@free.fr> wrote: >> >> > Le 16/08/2012 23:48, sebb a écrit : >> >> >> On 16 August 2012 21:58, Gilles Sadowski >> >> >> <gil...@harfang.homelinux.org> wrote: >> >> >>> Hello. >> >> >>> >> >> >>> In classes "HarmonicFitter" and "GaussianFitter" (in package >> >> >>> "o.a.c.m.optimization.fitting"), there is an inner class >> >> >>> "ParameterGuesser". >> >> >>> All the necessary input for the guessing procedure is passed to the >> >> >>> constructor; I thus propose that the guessing is performed at object >> >> >>> construction rather than at the call to the "guess()" method. This >> >> >>> will >> >> >>> allow to declare all the fields "final". Moreover, all that can go >> >> >>> wrong >> >> >>> will be located in the constructor, turning the "guess" method into a >> >> >>> mere >> >> >>> accessor. >> >> > >> >> > +1 to Gilles suggestion. >> >> > >> >> >> >> >> >> On the face of it, it sounds like the class does not even need to be >> >> >> instantiated. >> >> >> Could the guess method be turned into a static utility method to which >> >> >> the parameters are passed? >> >> >> Why bother creating an instance only to return the guess later? >> >> > >> >> > It could be. There are a bunch of methods involved and they exchange >> >> > data which is now stored in a few class fields (observation arrays and >> >> > the three estimated parameters), so these data should be added as >> >> > parameters to the static functions. >> >> > >> >> > I'm not sure whether it is cleaner to have a small instance created for >> >> > a short time to perform some difficult preprocessing or to have a bunch >> >> > of static methods. >> >> >> >> Instances need to be disposed of by GC whereas parameters >> >> automatically disappear when a called procedure returns. >> > >> > As a short-lived object, I guess that performance will not be improved >> > greatly (especially w.r.t. the time taken for the fitting itself). >> > >> >> A class with no fields is guaranteed immutable. >> > >> > The class will be immutable. >> > >> >> >> >> But for large numbers of parameters, class data is perhaps cleaner. >> > >> > Being "public", the inner class cannot disappear now; so I'll do the first >> > cleanup, and we'll see later if further changes are in order. >> >> Is the class directly usable by 3rd parties? > > Yes. > >> Would it make sense for a 3rd party to use it directly? > > Maybe. They could compare the guessed values with the optimized ones. > Admittingly, this is not very useful... if everything works fine. > >> >> If not, then although it would break strict binary compat., it would >> be possible to consider changing it. >> If it's not directly used by 3rd party code, I don't think changes can >> break their code. > > I don't understand: the class is public. Someone can have instantiated it in > his code...
Not if the following is true: >> If it's not directly used by 3rd party code >> >> Ideally any such helper classes should be private or package protected >> ab initio. > > I agree. > However in this case, the boundary between helper and utility (that could be > useful on its own) is not clear-cut. > > > 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
