commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [math] design patterns (was Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat UnivariateImpl.java)
Date Mon, 23 Jun 2003 21:40:22 GMT
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


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message