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 Fri, 04 Jul 2003 07:09:41 GMT

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message