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.
Hopefully my new experimental architecture alleviates this issue for univariate stats. There are currently three ways to get at the individual stats in my experimental refactoring. Static StatUtils, Non-static Univariate implementations and Direct Instantiation of a particular "UnivariateStatistic".
Various FrontEnd's <-- delegate to <-- Individual Stats.
<--StatUtils <----| Individual UnivariateStatistics <--Univariates <--|<-- (Mean, Var, Std, Sum, SumSq, <--Directly <-----| SumLog, Skew, Kurt, Percentile...)
The individual UnivariateStatistic's house the "guts" of the algorithms for both store based and storeless based calculations. You could instantiate these directly, call static instances of them via the StatUtils or Pickup a Univariate framework that will provide a "Standard Set" of them to work on a Storage Implementation.
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
Yes it is clearer, just for reference, my GC discussion at the beginning of this thread involved an article I read awhile back, this article suggested that objects that are created within a "static" method can get "stronger references" (or something along these lines) than their non-static counterparts and as such never actually get garbage collected over the life of the JVM. I can't, for the life of me, find this article again to backup my statement... Which leads me to think it was a Red Herring. :-(
-Mark
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
