-Mark
Tim O'Brien wrote:
-1, see previous discussion
On Tue, 17 Jun 2003, Mark R. Diggory wrote:
Proposal:
The deligation of UnivariateImpl to AbstractStoreUnivariate and refactoring of Univariate Interfaces.
Goals:
(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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
