commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: [math] design patterns (was Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat UnivariateImpl.java)
Date Fri, 20 Jun 2003 15:05:22 GMT
Phil Steitz wrote:

> Mark R. Diggory wrote:
>
>> David Graham wrote:
>>
>>> I see no correlation between AOP and static methods, nor any 
>>> correlation between static methods an increased code 
>>> maintainability.  There is nothing magic about static methods that 
>>> make them more maintainable than non-statics.
>>>
>>> David
>>>
>>>>
>>>> http://www.eclipse.org/aspectj/
>>>>
>>>> -Rob
>>>>
>> The discussion is growing somewhat repetative, OT and monotonic, 
>> unless anyone has a clearly differing view than whats been already 
>> voiced, I suggest we move on to more interesting development related 
>> topics, your probibly welcome to continue this discussion on the 
>> jakarta commons users/interest list.
>>
>> Cheers,
>
> I agree that this could go on and on and we should get back to work, 
> but I think that David's main point -- that static methods limit 
> flexibility and are not really necessary to support utility 
> functionality -- is a good one and one which we should keep in mind.  
> The limitation on overriding is a serious concern and that is why in 
> an earlier post, I suggested that we never use static methods for 
> complex algorithms. An argument could be made that it would have been 
> better to implement the methods in StatUtils as instance methods and 
> to provide a (singleton) instance factory for users. I think that this 
> is a better general approach, but for the simple computational methods 
> in StatUtils and MathUtils, convenience and efficiency outweigh the 
> extensibility concern.
>
> Phil 

True, there is a balance that needs to be maintained between 
extensibility and efficiency/ease of use.  David's comments about lack 
of extensibility in static methods is valuable. But, I certainly don't 
believe that static usage or instantiable objects are either right or 
wrong. They both have their place. I believe we based the design of the 
static utilities on the current Math design for consistency (not only in 
static aspects, but return value domain and behavior).

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.

-- 
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu



---------------------------------------------------------------------
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