The Override Problem

[Roedy Green]

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.

Any hints on techniques for ensuring the error never happens are
welcome or for finding them when suspected.

I love abstract methods. The compiler dutifully checked that I
remembered to implement every last one, to spell it perfectly and to
get the signature bang on.

But sometimes I want to provide a default implementation that I
occasionally override.

I tend to screw up and make a teensy spelling error in the name, or
get the method signature off by a hair. The compiler gives me no
warning at all. Basically my new methods is totally ignored and that
class uses the default implementation.

I wish there were syntax like this:

in my implementation, I use the keyword override to indicate I am
deliberately overriding a method in the base class. The compiler will
then warn me if I get the name or signature off.

There might be a keyword "original" to do the opposite, ensure I am
not overriding inadvertently a method in the base class or one
inserted later into the base class.


In the base class allow you to say something like

abstract for Dalmatian, Chow, BigDog

To force those classes to provide their own implementation and not
rely on the default one.


--
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

 

[Tom N]

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.

Any hints on techniques for ensuring the error never happens are
welcome or for finding them when suspected.

I love abstract methods. The compiler dutifully checked that I
remembered to implement every last one, to spell it perfectly and to
get the signature bang on.

But sometimes I want to provide a default implementation that I
occasionally override.

I tend to screw up and make a teensy spelling error in the name, or
get the method signature off by a hair. The compiler gives me no
warning at all. Basically my new methods is totally ignored and that
class uses the default implementation.

JBuilder provides an "override method" wizard which can insert stubs for all inherited abstract methods and can
insert stubs for selected inherited concrete methods. There is also a wizard to implement an interface.

Presumably some other tools will do something similar.

That solves the problem when initially writing the subclass but it doesn't handle the case where you either later
change the signature of the parent class abstract method or accidentally change the subclass by editing.

 

[-]

I wish there were syntax like this:

in my implementation, I use the keyword override to indicate I am
deliberately overriding a method in the base class. The compiler will
then warn me if I get the name or signature off.

There might be a keyword "original" to do the opposite, ensure I am
not overriding inadvertently a method in the base class or one
inserted later into the base class.

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

@Override
public void methodName() {

}

 

[Robert Klemme]

JBuilder provides an "override method" wizard which can insert stubs
for all inherited abstract methods and can insert stubs for selected
inherited concrete methods. There is also a wizard to implement an
interface.

I was going to say the same: use a decent IDE.

Presumably some other tools will do something similar.

Yes, eclipse has similar tools: you can select the methods you want to
override and get appropriate stubs.

That solves the problem when initially writing the subclass but it
doesn't handle the case where you either later change the signature
of the parent class abstract method or accidentally change the
subclass by editing.

No problem with eclipse if you use the refactoring "rename": all methods
in sub classes are changed similarly.

Kind regards

robert

 

[Andrew McDonagh]

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.

Any hints on techniques for ensuring the error never happens are
welcome or for finding them when suspected.

Yes, echoing the others response...use a decent IDE (Eclipse, IDEA, etc)
and stop typing.

alternatively, don't provide a default implementation - make it an
abstract method and LeanOnTheCompiler to tell you what to do.

Finally, if you had unittests for your code, they would fail straight
away, making it very very easy to find out that you'd misspelt the
method name/params.

Take a look at TestDrivenDevelopment.

Andrew

 

[Paul Bilnoski]

I wish there were syntax like this:

in my implementation, I use the keyword override to indicate I am
deliberately overriding a method in the base class. The compiler will
then warn me if I get the name or signature off.

There might be a keyword "original" to do the opposite, ensure I am
not overriding inadvertently a method in the base class or one
inserted later into the base class.

C# has special syntax for this if you're interested at all in looking at
that language's spec.
I guess that's one of the things the developers of that language noticed
as a problem in Java and tried to correct.
--Paul

 

[Andrea Desole]

@Override
public void methodName() {

}

this is probably the best solution, although you can still forget to
write the annotation.
Maybe future IDE versions will be able to give a warning if a function
without Override annotation is overriding another one

 

[Andrea Desole]

C# has special syntax for this if you're interested at all in looking at
that language's spec.

yes, it's the override keyword, not very different from the override
annotation already mentioned in the thread.

 

[Paul Bilnoski]

yes, it's the override keyword, not very different from the override
annotation already mentioned in the thread.

There is also 'new' on a method to show that it is not meant to override
one in the base class.
Roedy said he could use the @Override, but to do the opposite would need
some keyword 'original', which Java does not have an attribute type for
that I know of.
--Paul

 

[Tim Tyler]

Roedy Green wrote:

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

@Override
public void methodName() {

}

This is OK - but you *have* to be targetting Java 1.5.

If you want to build code which works on earier JVMs, it is of little
use.

 

[Yamin]

Yeah, a decent IDE will do the job. JBuilder for example will change
the font of the function name to indicate it is an overriden method.

You could of course use abstract method if you *have* to override the
method.

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.

Yamin Bismilla

 

[Andrea Desole]

There is also 'new' on a method to show that it is not meant to override
one in the base class.

true. I honestly don't miss it

Roedy said he could use the @Override, but to do the opposite would need
some keyword 'original', which Java does not have an attribute type for
that I know of.

I personally consider quite confusing to allow a method with the same
name in the derived class that doesn't override the same method in the
base class, but it hides it.
I would rather remove the 'original', and throw an error when the names
are the same (I actually think C# gives a warning in this case).

 

[Eric Sosman]

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.

Others have mentioned "software engineering" techniques
like annotations or override-aware IDEs. One thing I haven't
seen mentioned but that struck me as peculiar is

In the base class allow you to say something like

abstract for Dalmatian, Chow, BigDog

To force those classes to provide their own implementation and not
rely on the default one.

.... and the peculiar thing is that the base class is aware
of the subclasses that extend it, and even imposes constraints
on their implementations. And what happens when somebody
writes a new extending class OldYallerDog that ought (for some
perverted reason) not use the base class' method? The base class
has never heard of OldYallerDog, has therefore not "exported"
any constraints -- aren't you right back where you started?

IM(very)HO, a pattern like this is suggestive of a design
that might merit reassessment.

 

[Stefan Schulz]

this is probably the best solution, although you can still forget to
write the annotation.
Maybe future IDE versions will be able to give a warning if a function
without Override annotation is overriding another one

IIRC, eclipse already offers that.

 

[Joan]

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.

Any hints on techniques for ensuring the error never happens are
welcome or for finding them when suspected.

I love abstract methods. The compiler dutifully checked that I
remembered to implement every last one, to spell it perfectly and to
get the signature bang on.

But sometimes I want to provide a default implementation that I
occasionally override.

I tend to screw up and make a teensy spelling error in the name, or

How about spell checker. The first time you run it, you can create a list
of words that you can add to your checker. Then occasionally you just check
again and the
new words pop right up.

 

[Tim Tyler]

Paul Bilnoski wrote:

true. I honestly don't miss it

If you *consistently* mark the methods you override, marking ones
that you *don't* override is done implicitly and automatically.

 

[Andrea Desole]

If you *consistently* mark the methods you override, marking ones
that you *don't* override is done implicitly and automatically.

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.
Implicitly marking not overriding methods can be dangerous

 

[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.

However, unless you really need a base class implementation, interfaces
do something rather similar - so perhaps the idea is a bit esoteric.

 

[Andrea Desole]

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

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.

 

[Raymond DeCampo]

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. You can even apply it to methods
that exist in the superclass of the abstract class, forcing
re-implementation. For example:

public abstract boolean equals(Object obj);

However, unless you really need a base class implementation, interfaces
do something rather similar - so perhaps the idea is a bit esoteric.

Ray