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
