Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 27407 invoked from network); 17 Jun 2003 18:27:57 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 17 Jun 2003 18:27:57 -0000 Received: (qmail 20313 invoked by uid 97); 17 Jun 2003 18:30:20 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@nagoya.betaversion.org Received: (qmail 20306 invoked from network); 17 Jun 2003 18:30:19 -0000 Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12) by nagoya.betaversion.org with SMTP; 17 Jun 2003 18:30:19 -0000 Received: (qmail 41228 invoked by uid 500); 17 Jun 2003 17:23:43 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 41170 invoked from network); 17 Jun 2003 17:23:42 -0000 Received: from latte.harvard.edu (140.247.210.252) by daedalus.apache.org with SMTP; 17 Jun 2003 17:23:42 -0000 Received: from latte.harvard.edu (lorien.fas.harvard.edu [::ffff:140.247.212.206]) (IDENT: bgates, AUTH: PLAIN mdiggory, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by latte.harvard.edu with esmtp; Tue, 17 Jun 2003 13:23:49 -0400 Message-ID: <3EEF4F0F.2050106@latte.harvard.edu> Date: Tue, 17 Jun 2003 13:25:35 -0400 From: "Mark R. Diggory" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jakarta Commons Developers List Subject: Re: [math] [Proposal] Deligation of UnivariateImpl to AbstractStoreUnivariate and refactoring of Univariate Interfaces. References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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. -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: commons-dev-unsubscribe@jakarta.apache.org >>For additional commands, e-mail: commons-dev-help@jakarta.apache.org >> >> >> >> >> > > > --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org