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? Would it make sense for a 3rd party to use it directly? 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. Ideally any such helper classes should be private or package protected ab initio. > > 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
