The Override Problem

[Tim Tyler]

Some way of indicating methods that *must* be overriden in subclasses
may be an idea with some virtues.

That's what the abstract keyword does.[...]

....except that it doesn't work under some circumstances - thus my:
"unless you really need a base class implementation [...]" comment.

 

[Raymond DeCampo]

Andrea Desole <[email protected]> wrote or quoted:

yes, but the discussion is more about the case when you make a mistake
and you don't override a method that you should actually override.

Some way of indicating methods that *must* be overriden in subclasses
may be an idea with some virtues.

That's what the abstract keyword does.[...]

...except that it doesn't work under some circumstances - thus my:
"unless you really need a base class implementation [...]" comment.

I afraid you've lost me here. What use is the base class implementation
if your intent is that every subclass override the method?

If you intend to have every subclass invoke super.method1(), then it
would be better to have method1() be abstract in the superclass and ask
every subclass to invoke super.method2(), where method2() is protected.

Or actually, what would be better, would be to make method1() final in
the base class, have it invoke method2() and make method2() abstract and
protected.

So I don't really see the case you are addressing here.

Ray

 

[Roedy Green]

In your subclass use the '@Override' notation , eg.

is this just for decoration or will anyone check that it truly is an
override?

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Roedy Green]

Some way of indicating methods that *must* be overriden in subclasses
may be an idea with some virtues.

that's an abstract method if ALL must override.

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Roedy Green]

no, sorry, maybe I wasn't clear. I should have written "a method that
you want actually to override". I mean the case when you decide to
override a method, and you write a method with the same signature in
your class, but you don't explicitly say you are overriding a method,
because you forget or something else.

The theoretical problem I see is that when I write my code for class B
extending A, I choose method names not used in A. Then A's designer
comes along and adds a feature I have been telling him about for
general use. He of course uses my name for it and adds a method to his
A class without telling me.

If I am unlucky, my method accidentally OVERRIDES his, even though
they are only vaguely related.

Had I way of declaring my version original, when this happened I would
get a compile error.

You can have the same problem writing original code accidentally
overriding methods. If you are not familiar with class, you don't
know what method names are already taken. They may be taken 5 layers
of nesting deep.

Perhaps any method that overrides but does not call super should be
suspect.

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Roedy Green]

The othing thing you might want to do is provide a default method, but
print out some nasty error messag or even an exception if its actually
called. This will let u know immediately if somethig went wrong.

the catch is most of the time the default is fine. I just want a way
of ensuring when I do override, I have actually got the name and
signature perfect so my method won't be effectively as if I never
wrote it.

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Tim Tyler]

Tim Tyler wrote:
yes, but the discussion is more about the case when you make a mistake
and you don't override a method that you should actually override.

Some way of indicating methods that *must* be overriden in subclasses
may be an idea with some virtues.

That's what the abstract keyword does.[...]

...except that it doesn't work under some circumstances - thus my:
"unless you really need a base class implementation [...]" comment.

I afraid you've lost me here. What use is the base class implementation
if your intent is that every subclass override the method?

If you intend to have every subclass invoke super.method1(), then it
would be better to have method1() be abstract in the superclass and ask
every subclass to invoke super.method2(), where method2() is protected.

Or actually, what would be better, would be to make method1() final in
the base class, have it invoke method2() and make method2() abstract and
protected.

So I don't really see the case you are addressing here.

I did also say: "the idea is a bit esoteric".

I can imagine it happening, though - for example if you need the base
class to continue to perform the default functionality - because you have
already released it to clients and don't want to change your interface.

 

[Andrew McDonagh]

the catch is most of the time the default is fine. I just want a way
of ensuring when I do override, I have actually got the name and
signature perfect so my method won't be effectively as if I never
wrote it.

Then write a unit test to prove your class (regardless of its
inheritance hierarchy) performs as expected.

Any (Java) programmer who can't TDD will soon find their resumes
starting to be ignored.

Going from the paranoia you seem (in this thread) to be having with
people over riding methods willy-nilly or not because they can't use a
modern IDE properly, you may want to prevent method over riding all
together.

You make methods which derived classes can't over ride by using the
final keyword...

public final void someMethod() {}


With all due respect, you really seem to be making your development life
very hard by worrying about this and trying to find ways to prevent a
problem that percentage wise, just doesn't occur that often.

Stop worrying, start developing...

 

[Tim Tyler]

Any (Java) programmer who can't TDD will soon find their resumes
starting to be ignored.

Going from the paranoia you seem (in this thread) to be having with
people over riding methods willy-nilly or not because they can't use a
modern IDE properly, you may want to prevent method over riding all
together.

You make methods which derived classes can't over ride by using the
final keyword...

public final void someMethod() {}

With all due respect, you really seem to be making your development life
very hard by worrying about this and trying to find ways to prevent a
problem that percentage wise, just doesn't occur that often.

This is a real issue in complex projects - significant enough that
Sun introduced a directive specifically to deal with it.

 

[Chris Smith]

I am about the describe one of the most frustrating features of Java
-- the total lack of safety nets when it comes to overriding methods.
Tracking these down take me days.

Roedy,

The new Java 1.5 compiler (and the compiler in Eclipse 3.1) will enforce
the new annotation @java.lang.Override, which was added in Tiger. Both
compilers will produce an error message if you add this annotation to a
method that does not actually override the superclass. Eclipse can also
produce a warning if you DON'T add the annotation to a method that DOES
override the superclass, which solves your second problem.

The problem still exists, however, at the bytecode level. If you write
code against an old version of a library to extend a library class, and
then upgrade the library JAR file without recompiling your code, it's
still possible for a newly added library method to match your own code,
causing your code to inadvertently override a library method. A proper
solution would have addressed this, and so greatly reduced the "fragile
base class" problem that plagues inheritance-based designs.

In the base class allow you to say something like

abstract for Dalmatian, Chow, BigDog

This is a perversion of appropriate knowledge and distribution of
concerns. The above allows each subclass to determine its
implementation, and is generally a better solution.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Tim Tyler]

is this just for decoration or will anyone check that it truly is an
override?

Not just for show. See:

Java ->
Compiler ->
Errors/Warnings ->
J2SE 5.0 options ->
Missing @Override annotation

....in Eclipse.

 

[Chris Smith]

Roedy,

[...]

So I sent this right before realizing that I'd missed the rest of the
thread where seventeen people all said most of what I did. Sorry!

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Andrew McDonagh]

This is a real issue in complex projects - significant enough that
Sun introduced a directive specifically to deal with it.

Its a real problem for some large projects - thankfully none I've worked
on - maybe I've just been lucky....

Sun creates alot of directives, some good some bad, some just to say
that Java does XYZ because someOtherLanguage does XYZ.

 

[Chris Smith]

no, sorry, maybe I wasn't clear. I should have written "a method that
you want actually to override". I mean the case when you decide to
override a method, and you write a method with the same signature in
your class, but you don't explicitly say you are overriding a method,
because you forget or something else.

That's where Eclipse's warning comes in handy. After Eclipse corrects
you enough times, the @Override annotation starts to come naturally.
It's still not fool-proof, though.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Andrew McDonagh]

This is a real issue in complex projects - significant enough that
Sun introduced a directive specifically to deal with it.

Hmmm...one thought thats just struck me... is this problem just a
symptom of over using inheritance instead of favoring delegation?

The only times I seen this problem is when there is a deep inheritance
tree - by deep I mean more than 1 level of inheritance:

AbstractBase
^
SomeDerived // this is fine..
^
TheMostDerived // this is asking for trouble

^
any further derived classes means the design is plain wrong.

Andrew

 

[Raymond DeCampo]

Tim Tyler wrote:

Andrea Desole <[email protected]> wrote or quoted:

yes, but the discussion is more about the case when you make a mistake
and you don't override a method that you should actually override.

Some way of indicating methods that *must* be overriden in subclasses
may be an idea with some virtues.

That's what the abstract keyword does.[...]

...except that it doesn't work under some circumstances - thus my:
"unless you really need a base class implementation [...]" comment.

I afraid you've lost me here. What use is the base class implementation
if your intent is that every subclass override the method?

If you intend to have every subclass invoke super.method1(), then it
would be better to have method1() be abstract in the superclass and ask
every subclass to invoke super.method2(), where method2() is protected.

Or actually, what would be better, would be to make method1() final in
the base class, have it invoke method2() and make method2() abstract and
protected.

So I don't really see the case you are addressing here.

I did also say: "the idea is a bit esoteric".

I'm fine with considering esoteric examples.

I can imagine it happening, though - for example if you need the base
class to continue to perform the default functionality - because you have
already released it to clients and don't want to change your interface.

You can imagine what happening? Please be more explicit.

Are you saying that you have a method in a base class that you suspect
may or may not have been overridden in third party code using your
library? Now the semantics of the base class have changed to where each
extension should supply its own overridden version? If you leave the
existing implementation won't the client code then essentially be broken
and they won't have gotten any message from the compiler or at runtime
concerning the incompatibility? Wouldn't it be better to make the
method abstract and force them to override by contract?

I'm not trying to pick a fight, I'm trying to understand the situation
you have in your head.

Ray

 

[Thomas G. Marshall]

Raymond DeCampo coughed up:

Tim Tyler wrote:

quoted:

yes, but the discussion is more about the case when you make a
mistake and you don't override a method that you should actually
override.

Some way of indicating methods that *must* be overriden in
subclasses may be an idea with some virtues.

That's what the abstract keyword does.[...]

...except that it doesn't work under some circumstances - thus my:
"unless you really need a base class implementation [...]" comment.

I afraid you've lost me here. What use is the base class
implementation if your intent is that every subclass override the
method?
If you intend to have every subclass invoke super.method1(), then it
would be better to have method1() be abstract in the superclass and
ask every subclass to invoke super.method2(), where method2() is
protected.
Or actually, what would be better, would be to make method1() final in
the base class, have it invoke method2() and make method2() abstract
and protected.

So I don't really see the case you are addressing here.

I see that. You're missing the following notion I think:

Given two classes, in this relationship:

A <|-- B

Given the method

A.method()

It is not amazingly uncommon to see a situation where the designer wants an
implemented A.method() because the A class must be instantiatable, but for
all subclasses to require that the subclass override it with one of their
own. If the method were declared.

public abstract void method() {...}

Then there would never be any way to instantiate an A by itself. You can
make arguments as to whether or not this is something "good" to do in OO,
but I believe that it would be a "fine" thing to do if you had a keyword
enforcing it:

public must_override void method() {....}

But I'm not prepared to go to war over the notion. I've seen things be
declared non-abstract for this very reason alone.


--
Puzzle: You are given a deck of cards all face down
except for 10 cards mixed in which are face up.
If you are in a pitch black room, how do you divide
the deck into two piles (may be uneven) that each
contain the same number of face-up cards?
Answer (rot13): Sebz naljurer va gur qrpx, qrny bhg
gra pneqf naq syvc gurz bire.

 

[Raymond DeCampo]

Raymond DeCampo coughed up:

Tim Tyler wrote:


quoted:


yes, but the discussion is more about the case when you make a
mistake and you don't override a method that you should actually
override.

Some way of indicating methods that *must* be overriden in
subclasses may be an idea with some virtues.

That's what the abstract keyword does.[...]


...except that it doesn't work under some circumstances - thus my:
"unless you really need a base class implementation [...]" comment.

I afraid you've lost me here. What use is the base class
implementation if your intent is that every subclass override the
method?
If you intend to have every subclass invoke super.method1(), then it
would be better to have method1() be abstract in the superclass and
ask every subclass to invoke super.method2(), where method2() is
protected.
Or actually, what would be better, would be to make method1() final in
the base class, have it invoke method2() and make method2() abstract
and protected.

So I don't really see the case you are addressing here.

I see that. You're missing the following notion I think:

Given two classes, in this relationship:

A <|-- B

Given the method

A.method()

It is not amazingly uncommon to see a situation where the designer wants an
implemented A.method() because the A class must be instantiatable, but for
all subclasses to require that the subclass override it with one of their
own. If the method were declared.

public abstract void method() {...}

Then there would never be any way to instantiate an A by itself. You can
make arguments as to whether or not this is something "good" to do in OO,
but I believe that it would be a "fine" thing to do if you had a keyword
enforcing it:

public must_override void method() {....}

But I'm not prepared to go to war over the notion. I've seen things be
declared non-abstract for this very reason alone.

It strikes me that the "proper" way to do this would be to have an
abstract class and supply a particular implementation.

In this sense, "proper" means that this accomplishes the programming
semantics you desired using means supplied inherently by Java, without
depending on external programming contracts.

Thank you for the exposition.

Ray

 

[Andrea Desole]

The theoretical problem I see is that when I write my code for class B
extending A, I choose method names not used in A. Then A's designer
comes along and adds a feature I have been telling him about for
general use. He of course uses my name for it and adds a method to his
A class without telling me.

If I am unlucky, my method accidentally OVERRIDES his, even though
they are only vaguely related.

absolutely agreed. This is a good example

Had I way of declaring my version original, when this happened I would
get a compile error.

at least a warning.
But wouldn't you find a not overriding method in B with the same name,
although with 'original', a bit misleading? Wouldn't it be better to
change B's method name? With modern tools you can do that easily

Perhaps any method that overrides but does not call super should be
suspect.

Meaning that the overriding method has to be aware that it's overriding?
Still, a lot of methods don't call super. And you still have a problem
with abstract methods.

 

[Andrea Desole]

That's where Eclipse's warning comes in handy. After Eclipse corrects
you enough times, the @Override annotation starts to come naturally.

Yes, I finally saw it. I was using an older Eclipse version, because
with newer versions I can't use the JBoss IDE. Now I finally saw it on a
3.1 final

It's still not fool-proof, though.

the warning? With Eclipse you have the possibility to give an error. Of
course, you have to set it (default is 'ignore')