On 8/6/13 7:27 AM, Ajo Fod wrote: > Is this an issue then? Best not to top-post. Lets see if we get any other views on how the setup may be improved. Then when we have consensus that a design change is warranted and what that change will be, we can open a ticket to track the work.
Phil > > -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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
