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. A class with no fields is guaranteed immutable. But for large numbers of parameters, class data is perhaps cleaner. > Luc > >> >>> OK? >>> If so, do I need to file a JIRA ticket for this change? >>> >>> >>> 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 >> >> > > > --------------------------------------------------------------------- > 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
