robert burrell donkin wrote:
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
Mark R. Diggory wrote:
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
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
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.
Phil Steitz wrote:
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
Al,
It sounds like the pattern you're proposing is the Strategy design
pattern (see Design Patterns by the four authors). Basically, an object
has multiple possible delegate objects, each of which implement a common
interface. Then, as the state changes, the strategy can switch from one
David Graham wrote:
--- David Graham [EMAIL PROTECTED] wrote:
Maybe I'm unique, but
sometimes I find that Java (as well as other languages) gets in
my way
rather
than letting me solve the problem at hand in a natural way.
You're not alone in that belief. I've heard several people
Static methods are a necessary evil in OO languages and should be
avoided when possible.
I disagree. Static functions are similar to Aspect Oriented Programming,
such as AspectJ which centrializes
code across many classes that is similar in functionality. This
eliminates duplicate code, and
David Graham wrote:
Static methods are a necessary evil in OO languages and should be
avoided when possible.
I disagree. Static functions are similar to Aspect Oriented
Programming, such as AspectJ which centrializes
code across many classes that is similar in functionality. This
eliminates
David Graham wrote:
Static methods are a necessary evil in OO languages and should be
avoided when possible.
I disagree. Static functions are similar to Aspect Oriented
Programming, such as AspectJ which centrializes
code across many classes that is similar in functionality. This
eliminates
[EMAIL PROTECTED] wrote:
- * This product includes software developed by the
+ * This sumLog includes software developed by the
The traps of global sr, I guess... :-)
J.Pietschmann
-
To unsubscribe, e-mail:
-1 on that specific commit.
As the originial contributor, I believe you have voting rights for this.
I'd concur on this one. UnivariateImpl is an optimized, performance
oriented storage-less implementation, StoreUnivariate captures another
set of requirements entirely.
Tim
On Tue, 17 Jun
-1,
Lets be clear here, your telling me that you think that
AbstractStoreUnivariate is a Heavy Implementation and that somehow
implementing the entire implementation and interface again in
UnivariateImpl to support the same functionality there is somehow
lighter? I entirely disagree with
13 matches
Mail list logo
