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.
-Mark
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
