Why can't static methods be overridden?

B

bernd_no_junk

Quite often I have a hierarchy of classes where
I want a specific accessor method to be
present in all classes. Therefore I specify
it in the base class. But the information
that this function returns only depends on the
actual class, so it should static, shouldn't it?

I ran into the neccessity to do so sometimes
during design and started wondering why Java
actually forbids it.

Is there a specific OO reason?


Regards,

Bernd
 
O

Owen Jacobson

Quite often I have a hierarchy of classes where
I want a specific accessor method to be
present in all classes. Therefore I specify
it in the base class. But the information
that this function returns only depends on the
actual class, so it should static, shouldn't it?

I ran into the neccessity to do so sometimes
during design and started wondering why Java
actually forbids it.

Is there a specific OO reason?

This seems to be related to the recent discussion about invoking static
methods through instances. Consider if derived classes could override
static (class-scope) methods:

class A {
static void something () {}
}

class B extends A {
static void something () {}
}

....
A anA = new B ();
anA.something (); // This is valid, modulo B.something ()'s existence

Which 'something' should be invoked, here? Currently the rules say that
A.something should be invoked, but if it were possible to override
something in derived classes you can bet people would then want to be able
to call derived static methods through base class references, which I can
only assume the Sun guys feel is much less straightforward than the
current mechanism.

For what it's worth I agree with them.
 
T

Tor Iver Wilhelmsen

Is there a specific OO reason?

It would have been clearer if Sun hadn't made the error of letting you
access static members via instance references. The latter can fool
people into thinking that they are more dynamic than they are.

The likely reason is that Java doesn't have "class objects" unlike
some other languages; if it had, static methods would be "virtual"
methods in these objects. (The class java.lang.Class is a metaclass.)
 
B

bernd_no_junk

Currently the rules say that
A.something should be invoked, but if it were possible to override
something in derived classes you can bet people would then want to be able
to call derived static methods through base class references

I would like to do that as well....
which I can
only assume the Sun guys feel is much less straightforward than the
current mechanism.

Why ? The method was overridden, so the derived method should be
called.

regards,

Bernd
 
B

bernd_no_junk

It would have been clearer if Sun hadn't made the error of letting
you
access static members via instance references. The latter can fool
people into thinking that they are more dynamic than they are.

I agree that this is broken and should be removed.
The likely reason is that Java doesn't have "class objects" unlike
some other languages; if it had, static methods would be "virtual"
methods in these objects. (The class java.lang.Class is a metaclass.)

Yes, I know this from c++ as well. And would find it useful in Java,
too.

Regards,

Bernd
 
C

Chris Uppal

Quite often I have a hierarchy of classes where
I want a specific accessor method to be
present in all classes. Therefore I specify
it in the base class. But the information
that this function returns only depends on the
actual class, so it should static, shouldn't it?

No. The "static" concept in Java is designed to be misleading. Ask yourself
these question "is /that specific/ object supposed to be able to supply the
information?", and also "is /that specific/ object supposed to be the
authoritative source of the information?". If the answer to the first question
is yes, and especially if the answer to the second question is yes, then the
method should be an instance method.

The chances are that one or the other answer is yes. So, even if the method
does not directly involve any specific state of any specific object, it should
still be an instance method.

The way I like to think of it is that the "class" is a separate object from all
its instances, and that it's of a different class (one with no name), and that
the static methods and fields are "really" instance members of that class
object. (Smalltalk programmers will recognise this picture.) Unfortunately,
that isn't how Java really works, so the picture is misleading in too many
ways, but what it /does/ capture accurately is the split in responsibility
between the class and any of its instances. The question is always "whose job
is it so supply such-and-such information / such-and-such service?", is it the
instance, or is it the class ? Looked at that way there is less confusion in
the cases where -- in principle -- either /could/ supply the
information/service because it's not actually instance-specific; it will
normally be clear /who's/ job it is.

I ran into the neccessity to do so sometimes
during design and started wondering why Java
actually forbids it.

Is there a specific OO reason?

Yes, it's because "static" in Java has nothing to do with -- in fact is
antithetical to -- OO concepts and OO programming.

-- chris
 
V

VisionSet

Quite often I have a hierarchy of classes where
I want a specific accessor method to be
present in all classes. Therefore I specify
it in the base class. But the information
that this function returns only depends on the
actual class, so it should static, shouldn't it?

I ran into the neccessity to do so sometimes
during design and started wondering why Java
actually forbids it.

Is there a specific OO reason?

I find it helpful to think of static as per inheritence hierachy rather than
per class.
 
J

Joona I Palaste

Yes, it's because "static" in Java has nothing to do with -- in fact is
antithetical to -- OO concepts and OO programming.

When I did my Java data structures programming laboratory, the
instructor had a simple rule: "as few 'static's as possible". I wrote a
Java program with only one 'static': The main() method in the central
application class. I got full marks for that laboratory.
 
X

xarax

Quite often I have a hierarchy of classes where
I want a specific accessor method to be
present in all classes. Therefore I specify
it in the base class. But the information
that this function returns only depends on the
actual class, so it should static, shouldn't it?

We use the term "method", instead of "function".

In addition to all of the other good answers,
I'll reply that you may be looking for an
abstract method in the abstract base class. The
concrete subclass provides that actual "smarts" for
the method and it can vary by subclass.

A simple-minded example:
==========================
public abstract class Polygon
{
public abstract int area();

public abstract int perimeter();

public Polygon()
{
super();
}
}

public class Rectangle
extends Polygon
{
protected final int side1;
protected final int side2;

public int area()
{
return side1 * side2;
}

public int perimeter()
{
return 2 * (side1 + side2);
}

public Rectangle(final int theSide1, final int theSide2)
{
super();

side1 = theSide1;
side2 = theSide2;
}
}

public class Square
extends Rectangle
{
public int perimeter()
{
return 4 * side1;
}

public Square(final int theSide)
{
super(theSide,theSide);
}
}
==========================

The area() and perimeter() instance methods
are abstract in the base class. The concrete
subclasses provide their implementations that
are appropriate for their subtype. Anywhere
that the client code uses a Polygon, a Rectangle
or Square could be the actual type. Anywhere
that a Rectangle is used, it could be a Rectangle
or a special case of a rectangle called a Square.

I suggest using a factory method to instantiate
the concrete subtype and return the abstract
base type. The factory method could use parameters
to determine which actual subtype to create, thus
insulating the client code from knowing the actual
subtype.

--
----------------------------
Jeffrey D. Smith
Farsight Systems Corporation
24 BURLINGTON DRIVE
LONGMONT, CO 80501-6906
http://www.farsight-systems.com
z/Debug debugs your Systems/C programs running on IBM z/OS for FREE!
 
Y

Yakov

You can override a method that belongs to a particular instance of the
object that represents your class. But your static method belongs to
all instances hence you can't override it.

Regards,
Yakov
 
Y

Yakov

When I did my Java data structures programming laboratory, the
instructor had a simple rule: "as few 'static's as possible". I wrote a
Java program with only one 'static': The main() method in the central
application class. I got full marks for that laboratory.

Congratulation on your full marks, but your teacher is not that great.
A statement "as few instance's as possible" would be equally wrong.

Regards,
Yakov
 
J

John C. Bollinger

Chris said:
No. The "static" concept in Java is designed to be misleading. Ask yourself

I've never heard it put quite that way before. :)
The way I like to think of it is that the "class" is a separate object from all
its instances, and that it's of a different class (one with no name), and that
the static methods and fields are "really" instance members of that class
object. (Smalltalk programmers will recognise this picture.)

I'm not a Smalltalk programmer, but I have come to exactly the same
mental model. As you say (elided) that model can be misleading,
especially if pushed too far or if incorrect assumptions are made (e.g.
about there being any inheritance relationships among the hypothetical
class classes). Nevertheless, to a first approximation it does a good
job of explaining the nature and use of classes' static members.
Yes, it's because "static" in Java has nothing to do with -- in fact is
antithetical to -- OO concepts and OO programming.

That sounds a bit strong, but after thinking about it I have to agree.

John Bollinger
(e-mail address removed)
 
J

Joona I Palaste

I'm not a Smalltalk programmer, but I have come to exactly the same
mental model. As you say (elided) that model can be misleading,
especially if pushed too far or if incorrect assumptions are made (e.g.
about there being any inheritance relationships among the hypothetical
class classes). Nevertheless, to a first approximation it does a good
job of explaining the nature and use of classes' static members.

However, with a bit of practice, the Smalltalk object model can be
simulated using Java. You just have to use regular objects as class
objects and then pass a reference to them to any "normal" objects you
create.

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"You have moved your mouse, for these changes to take effect you must shut down
and restart your computer. Do you want to restart your computer now?"
- Karri Kalpio
 
C

Chris Uppal

Yakov said:
When I did my Java data structures programming laboratory, the
instructor had a simple rule: "as few 'static's as possible"
[...]
but your teacher is not that great.
A statement "as few instance's as possible" would be equally wrong.

I'd give full marks to the instructor too.

Admittedly, the statement: "as few 'static's as possible" needs qualification
(static final constants do little harm, for instance), but as a rule of thumb
it's right on the money.

-- chris
 
C

Chris Uppal

John said:
I've never heard it put quite that way before. :)

<grin> OK, I admit the sentence didn't come out the way I'd intended.

Still, thinking about it, I'm not so sure I want to withdraw the statement.
I'm well aware of the rule "never attribute to malice what can be sufficiently
explained by stupidity", but sometimes I wonder about Java "static"...

Consider:

) The syntax rule that allows you invoke static members as if they were
instance members.

) The Sun coding guideline that gives more prominence to
public/protected/private than to static/non-static.

) The really absurd details of method lookup in the JVM spec, where it is
/required/ that you find the member without considering whether it's static or
not, and only once it has been found (if it has) can you consider whether it's
"staticness" is appropriate to the way it's being called, invokevirtual vs
invokestatic. (This observably affects the exceptions that are thrown if the
lookup fails)

) The fact that JavaDoc doesn't group static methods separately from instance
methods.

The case rests...

-- chris
 
C

Chris Uppal

Joona said:
[...]
However, with a bit of practice, the Smalltalk object model can be
simulated using Java. You just have to use regular objects as class
objects and then pass a reference to them to any "normal" objects you
create.

Yes indeed. (Actually, I'd say that the reference to the shared "class" object
is a candidate for making into a private static final field, rather than being
shared explicitly.)

Too much bother for me, though, as a regular rule (though I am often tempted).
I just stick to using Smalltalk whenever I can[*].

-- chris

[*] there are many other reasons, of course, why I prefer to use Smalltalk
wherever possible, but this is not the place to enumerate them.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,577
Members
45,052
Latest member
LucyCarper

Latest Threads

Top