commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <>
Subject Re: [math] design patterns (was Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat
Date Tue, 24 Jun 2003 00:18:47 GMT
robert burrell donkin wrote:

> On Friday, June 20, 2003, at 05:34 PM, Phil Steitz wrote:
>>> I keep reminding myself, we are the developers, there is always room 
>>> for refactoring in the future. If there becomes a clear hindrance 
>>> with the use of static methods, then we can refactor them into a 
>>> class that needs to be instantiated. This is not too difficult to 
>>> accomplish.
>> Not for us, maybe, but it could be a real pain for the users who have 
>> written code using the static methods directly. We also need to keep 
>> reminding ourselves that what we are developing is a library for 
>> others to use.  Refactoring public interfaces post release is a slow 
>> and painful process. Given that MathUtils and StatUtils are going to 
>> be public, we need to be committed to supporting the static methods 
>> that they will expose.  I am personally OK with this, as long as we 
>> limit the scope to relatively trivial computational methods.
> we came across this very problem in beanutils not too long ago. 
> beanutils was originally written to use static utility methods. we 
> ended up creating (pseudo-)singletons that do the actual work. this 
> has turned out to have more than a few wrinkles (since jakarta 
> components are designed to be used in server applications, there's a 
> lot to think about when it comes to ensuring that objects can be 
> garbage collection and that different web applications use independent 
> versions of configurable library code).
> i personally think that there is probably room for a few headline 
> classes of this type at the top of the hierarchy in order to make 
> things easy for basic users. but i would probably advise developers of 
> library code to prefer concrete objects for advanced classes. 
> experience has shown that these may need to be sub-classed or have to 
> make use of the strategy pattern later. i would say that retro-fitting 
> these capabilities to an existing library can prove to be very 
> non-trivial.
> anyway, i'll be interested to see what J.Pietschmann comes up with.
> - robert

This is a really strong point Robert, I know there are real issues with 
objects that get created from a static point not getting garbage 
collected from some applications I worked on, I shouldn't have assumed 
it wasn't an issue in the server env. I'd have to say, this is the 
strongest point I've seen so far for singleton object usage over static 
util usage and its quite convincing to me.

 I think I actually have somewhat of an interesting solution to this. 
But I want to get it fully formalized to present to the group, I have an 
alternative implementation of some of the stat/StatUtil classes that I 
will present to the group within the next day or so.


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

View raw message