commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Graham" <>
Subject Re: [math] design patterns (was Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat
Date Thu, 19 Jun 2003 19:39:15 GMT
>I agreed with you upto that last sentence, My viewpoint: The whole point of 
>the java.util.Math class is that the functions are so "standardized" and so 
>"final" (on top of that mostly "native") that they shouldn't really ever be 
>"overridable", they are "utility" functions that one can "rely" to be of a 
>specific mathematical/numeric behavior. They are static as well to be 
>easily accessible.

Attaching methods to number objects makes them easily accessible too.

>IMHO, Static functions are the closest Java ever comes to allowing 
>developers to define their own "operators". They are as analogous to the 
>concept of mathematical functions as you can get. Did you ever write 
>-1.cos() in Calculus? no, you wrote cos(-1) , and in java Math.cos(-1).

This isn't calculus, this is OOP.  I'm of the opinion that in OOP you should 
always be passing messages to objects and static methods violate that 
principal.  If I want to find the cosine of some number variable x it's more 
natural OOP to say x.cos().  cos(x) is a very procedural (read C) way of 
thinking and unnecesarily limits your implementation possibilities.

Anyways, this discussion is purely academic because we're constrained by 
what Java actually allows.  I'll let you math wizards get back to work ;-).


>Another example of  this the finality of java.lang.Number's like Double, 
>Integer, etc. At first when I started to work with them, I wanted to be 
>able to do things like
>Double x = new MyDouble(1.0);
>Double y = new MyDouble(2.0);
>Double z = x.add(y);
>But, this again introduces room for a sort of operator overloading which 
>Java works hard to avoid (KISS).  I now see why this is unfavorable.
>MathUtils and StatUtils fall under this branch of design, they are die hard 
>final implementations of a specific function that will be capable of being 
>relied on in a similar fashion as the Math class.
>>Exactly.  Any time you need a utility class with static members you can 
>>replace it with a Singleton object with non-static methods.
>If there are other reasons for making methods static, then this just 
>introduces unnecessary complexity. Math.pow(x,y) is always much easier to 
>do than
>Math math = Math.newInstance();
>(not that, this is very hard at all either).
>Now, the benefit of having both StatUtils and AbstractStoreUnivariate, is 
>that you now have easy static reliable, final access via StatUtils when you 
>want it, and you can override/extend the capabilities of 
>AbstractStoreUnivariate when you want to create a custom implementation of 
>an approach.   Tim, Phil and Al were quite right to have me rollback what I 
>had initially committed, this is far more flexible. Flexibility is very 
>important in the initial stages of project development.
>Finally, I really feel Aspect Oriented Programming ( really 
>takes OOP to the next level where some class/objects are now acting as 
>functional relationships between other classes/objects. I would be more 
>interested in how AOP could be applied to our libraries vs good ol' OOP.
>To unsubscribe, e-mail:
>For additional commands, e-mail:

Help STOP SPAM with the new MSN 8 and get 2 months FREE*

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message