-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] > > > -- ---------------------- Tim O'Brien Evanston, IL (847) 863-7045 [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
