commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] caching factory / object instances
Date Sun, 06 Jun 2004 02:46:14 GMT
Mark R. Diggory wrote:
> My major concern is that there are multiple usecases here, even in your 
> code example:
> DistributionFactory factory = DistributionFactory.newInstance();
> vs.
> DistributionFactory factory = DistributionFactory.getInstance();
> Here, the first case may construct a DistributionFactory where some 
> internal state/environment is maintained which makes it different than 
> another DistributionFactory. You can see this sort of case in examples 
> such as SAX and JAXP where the Factory instance is configurable and 
> produces objects with different states.
> In another example, with DescriptiveStatistics.newInstance() we have an 
> issue where the instantiated factory is also the object, it has unique 
> state we want to maintain multiple instances of the object. Having these 
> methods be getInstance instead of newInstance would be very limiting.

Good point.  Also don't want them to be singletons. I probably should have 
limited scope to the distribution and solver factories (you have more or 
less convinced me, in any case, that the stats thingies are not really 
factories anyway ;-).

> Right now DistributionFactory has no state that would make it anymore 
> unique than any other distribution factory. Which makes me think your 
> suggested change would be fine. But, maybe we should evaluate if we 
> think a Factory is going to have greater capability or configurability 
> in the future and try not to shoot ourselves in the foot by limiting it 
> to a singleton status.

Another good point -- maybe it is best to leave the factory instance 
caching to the client.
> Finally, I wonder, if your going to reuse the object as a singleton, do 
> synchronous issues arise with concurrent access via the methods in the 
> factory?

Another good point to consider, though I don't see how this would be a 
problem for the distribution or factories, since these factories have no 
state; but then again if they ever do become stateful, this will be an issue.

I am inclined now to close the getInstance part of the bug as WONTFIX and 
just fix TTestImpl.  The one thing that I would like to fix is the 
behavior when discovery fails (catching the exception and returning an 
instance of the default factory). Among other things, that will allow us 
to make [discovery] (and hence [logging]) optional.


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

View raw message