commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <>
Subject Re: [math] [Proposal] Deligation of UnivariateImpl to AbstractStoreUnivariate and refactoring of Univariate Interfaces.
Date Tue, 17 Jun 2003 17:25:35 GMT
Please be more verbose, are you voting -1 on everything in this message, 
there is more than one recommendation in the proposal. Also, I was using 
this message to formalize and clarify the changes that I an 
recommending, as such I'm trying to make this the point from which more 
formal discussion on this topic can extend from.


Tim O'Brien wrote:

>-1, see previous discussion
>On Tue, 17 Jun 2003, Mark R. Diggory wrote:
>>The deligation of UnivariateImpl to AbstractStoreUnivariate and 
>>refactoring of Univariate Interfaces.
>>(1) I propose that UnivariateImpl should deligate to either a full 
>>implmentation of StoreUnivariate or it should extend the 
>>AbstractStoreUnivariate instead of supporting multiple implementations 
>>of the "Statistical Methods" for StoreUnivariates and UnivariateImpl. 
>>This way there is only one implementation for a stored statistical 
>>method approached in AbstractStoreUnivariate. It is the case then that 
>>when UnivariateImpl has a window and requires storage, that it uses the 
>>same exact implementation as other storage implementations.
>>(2) Simplification of the Univariate/StoreUnivariate Interfaces. With 
>>the above case in mind, there are "methods" that currently do not have 
>>storageless implementations, but when in a storage based mode, 
>>UnivariateImpl becomes a storage based implementation, as such those 
>>methods are now available through the deligation. It is benifical then 
>>to provide acces to those methods throught the Univariate Interface 
>>itself. I propose the consolidation of the StoreUnivariate and 
>>Univariate into one interface (and in the minorboolean cases where a 
>>UnivariateImpl method is not currently applicable, to just throw a 
>>runitime exception).  Initially, we found storageless implmentations of 
>>some statistics to be difficult to accomplish. But I feel strongly that 
>>over time clean solutions will be found, we should not lock ourselves 
>>out of accomplishing this be restricting the interface.
>>I propose a class heirarchy/naming change to occur based on the 
>>following class structure
>>public interface Univarate
>>    - combines Univariate and StoreUnivariate
>>    - *defines all Univariate stat and storage access methods*
>>public abstract class AbstractUnivariate implements Univariate
>>    - was AbstractStoreUnivariate
>>    - *implements All Univariate Statistics and storage access*
>>public class RollingUnivarate extends AbstractUnivariate
>>     - *storage access and some stats only available when window is set*
>>public class StoreUnivariateImpl extends AbstractUnivariate
>>public class ListUnivariateImpl extends AbstractUnivariate
>>public class BeanListUnivariateImpl extends AbstractUnivariate
>>Lastly, if the above approach is rejected by the group, then I highly 
>>recommend that there be separate implementations of the storageless 
>>"RollingUnivariate" and storage based "RollingStoreUnivariate" to reduce 
>>the  both interface confusion that is currently observable in the 
>>package between Univariates and StoreUnivariates and the implementation 
>>complexity observed in the current UnivariateImpl approach.
>>-Mark Diggory
>>Software Developer and Project Manager
>>Harvard MIT Data Center
>>To unsubscribe, e-mail:
>>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message