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:
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 se
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 t
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 to
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.
Dav
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 d
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 d
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 i
David Graham wrote:
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 th
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 se
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
11 matches
Mail list logo