On Tuesday, June 24, 2003, at 01:18 AM, Mark R. Diggory wrote:
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'm sorry since i think i've managed to confuse people. (i do that quite often.)
(this is from the perspective of libraries used in j2ee applications.)
booch utilities (classes with static method which are functions) are ok so long as they are simple. users find them very easy to use and are a good way to make the simplest functions in library readily available to users. there is no real reason why simple booch utilities should require violation of good object oriented principles elsewhere in the library - a function can be delegated to an instance of an object. this delegate may be a singleton.
the difficulty comes when state is needed. users commonly ask for this kind of enhancement so that options can be configured or to allow a strategy to be set. the easiest way to provide them with setters and getters in the utility class. this approach is a poor one since these fields will be shared with everything else in the classloader. for reusable common library code, this is a major issue.
a slightly more sophisticated approach would be to make the utility delegate to a singleton instance of a object which can also be constructed.
the user can then choose whether to construct an instance and then configure it or use the utility and use the standard settings. the library should *not* expose the singleton delegate or allow the user to set any state on that object. the user *must* create an instance in order to use any advanced features. this is the pattern that i would advocate for advanced booch utilities.
why? well, now consider the case when you allow the user to configure the booch utility directly (this is the beanutils case). now, so that you can isolate threads in different server side contexts, you need to use a pseudo-singleton - a singleton that is a singleton for each server side context rather than per classloader. this turns out to be non-trivial when you realize that every time a context is disposed of, everything needs to be garbage collected and that users are going to want to be able to subclass the bean pseudo-singleton.
i hope this is a bit clearer now.
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
