Is this an issue then? -Ajo
On Fri, Aug 2, 2013 at 3:48 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > On 8/2/13 3:09 PM, Ajo Fod wrote: > > The class design of AbstractStorelessStats (Storeless) suggests that it > is > > storing data in its parent AbstractUnivariate (Parent) and there are > > methods accesible to a child of this class that shouldn't be to something > > that is storeless in: > > > > private double[] storedData; > > > > ... perhaps Percentile etc should inherit from another subclass of the > > Parent? > > > I agree that there is no reason that > AbstractStorelessUnivariateStatistic should extend > AbstractUnivariateStatistic and the smelliness of exposing getData > in the child is a good reason for it *not* to. I think the > implemented interfaces do make sense to inherit from one another, > but the abstract parents should be independent. While cleaning this > up, I would also nuke the argumentless evaluate() from > AbstractUnivariateStatistic. > > Percentile in its current implementation requires the data to be > stored in memory, so it is not a "storeless" - i.e., it should > inherit as it does from AbstractUnivariateStatistic. We have been > talking about implementing a "storeless" approximation algorithm, > but that should go in a new class which would inherit from > AbstractStorelessUnivariateStatistic. > > There may be other reasons that I don't remember for why the > abstract parent inheritence is there. But those should be picked up > by the unit tests. Any better ideas on how to achieve what we have > been achieving with these classes? As I said above, as long as the > tests pass with only trivial mods, I am OK breaking the parent / > child on the abstract parents. Now is a great time to think about > other ways to make the code easier to understand / use. > > Phil > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
