force method to be overriden in subclasses

[Tian Zhang]

hello,

is there a way to force the subclass to override a method? so far this is the solution that i have come up with:

public class Mother{
public void overrideMe() throws MethodNotOverridenException{
throw new MethodNotOverridenException("need to over me");
}
}
 
public class MethodNotOverridenException extends RuntimeException{
public MethodNotOverridenException(String msg){
super(msg);
}
}
 

then when extended:

 
public class Child extends Meh{
...
}

this solution is about as ugly as it gets (sorry if this solution has offended anyone )

please note that i am extending, not implementing.

thanks
[ March 27, 2005: Message edited by: Tian Zhang ]

[Keith Lynn]

Actually the keyword abstract is designed to solve this problem.

If a method in a superclass is abstract, then if a subclass wants to be instantiated, then it will be forced to give the abstract methods it inherits an implementation.

[David Harkness]

This is exactly the solution I've used for many years starting with C++ when a method must be overridden if it is used. In other words, the functionality is optional, but if you make use of it, you have to override a method to fill in some details.

If, however, the method must be overridden no matter what, simply declare it abstract in the superclass and remove the implementation that throws the exception. You also must declare the superclass itself abstract. Now a subclass must override it or be declared abstract itself. Of course, abstract classes may not be instantiated, so this forces overriding of the method.

[Jim Yingst]

I'd note that if you do find yourself in a situation where you choose to throw an exception rather than declare the method abstract, there's a standard class for this already: java.lang.UnsupportedOperationException.

[Tian Zhang]

if i append abstract to the method declaration i get a "abstract method not allowed in non-abstract class":

    abstract protected void loadDefaultInterfaces() throws InvalidInterfacesException;

though on second thoughts this must be the case. in a nonabstract class methods cannot be abstract, as this would cause problems if the class is instantiated and the "abstract" method being called.

i guess throwing exceptions are the only way to force override.

thanks,

p.s. please let me know if i am wrong
[ March 27, 2005: Message edited by: Tian Zhang ]

[Keith Lynn]

Consider this as an example.

public abstract class MyClass {
 
   public abstract int numbers();
 
}

public class MyNuClass extends MyClass {
 
}

The only way that you can make an instance of MyNuClass is to override and implement numbers().

[marc weber]

If you're using Java 5.0, the @Override annotation forces a method to override the superclass version. A compile-time error results if it doesn't. However, this annotation is used in the subclass -- not the superclass. It's basically to ensure that the method is actually overridden rather than just overloaded.
[ March 27, 2005: Message edited by: marc weber ]

[David Harkness]

Originally posted by Tian Zhang:
though on second thoughts this must be the case. in a nonabstract class methods cannot be abstract, as this would cause problems if the class is instantiated and the "abstract" method being called.

Classes with inherited or declared abstract methods must be declared abstract and cannot be instantiated. In your first example, if you required Mother to be non-abstract (sometimes called concrete), then using an exception is your only option.

Keep in mind, however, that an abstract method truly forces overriding -- it won't compile otherwise. Using an exception only fores the issue at runtime which raises the possibility of a bug.

[Ilja Preuss]

Why do you need to declare the method in the superclass? Can't you just have the appropriate subclasses implement an addtional interface?

[David Harkness]

Originally posted by Ilja Preuss:
Why do you need to declare the method in the superclass? Can't you just have the appropriate subclasses implement an addtional interface?

When I've used this technique, it is because the abstract superclass needs to call the abstract method but cannot provide a reasonable default behavior for the method. If the superclass doesn't declare it, it cannot call it and let the subclass provide an implementation.

[Tian Zhang]

Ilja Preuss do you mean the following solution:

public class Person{...}
public interface Child{
public void mustOverride();
}
 
public class Meh extends Mother implements Child{
// forced to override mustOverride() here
}

though on second thoughts i do not require the super to be concrete, in which case i would guess that Keith Lynn's solution would be more appropriate. (i am guessing that the main advantage of extracting the interface is that it allows the "Person" class to be concrete).

thanks

[Ilja Preuss]

Originally posted by David Harkness:
When I've used this technique, it is because the abstract superclass needs to call the abstract method but cannot provide a reasonable default behavior for the method. If the superclass doesn't declare it, it cannot call it and let the subclass provide an implementation.

Yes. But then of course *every* subclass needs to define the method, doesn't it?

[Ilja Preuss]

Originally posted by Tian Zhang:
Ilja Preuss do you mean the following solution:

public class Person{...}
public interface Child{
public void mustOverride();
}
 
public class Meh extends Mother implements Child{
// forced to override mustOverride() here
}

Yes, that's what I meant.

though on second thoughts i do not require the super to be concrete, in which case i would guess that Keith Lynn's solution would be more appropriate. (i am guessing that the main advantage of extracting the interface is that it allows the "Person" class to be concrete).

Correct - if you don't need the superclass to be concrete and every subclass needs to define the method, declaring it abstract is the right thing to do.

The solution above is ment for cases where only a subset of the subclasses needs to define the method.

[David Harkness]

Originally posted by Ilja Preuss:
Yes. But then of course *every* subclass needs to define the method, doesn't it?

Of course, that's precisely the point. When the method is optional, I use the UnsupportedOperationException route instead of making it abstract.

[marc weber]

My understanding is that RuntimeExceptions should not be used for situations that could be avoided by proper coding. So could someone please explain the rationale for using an UnsupportedOperationException in this case?

[David Harkness]

Originally posted by marc weber:
My understanding is that RuntimeExceptions should not be used for situations that could be avoided by proper coding.

I've always felt the exact opposite.

IllegalArgumentException

Array/StringIndexOutOfBoundsException

NullPointerException

ConcurrentModificationException

These are all cases that a good programmer will avoid. Given that, I don't want to be forced to write a bunch of catch blocks that will never be activated because, well, I employ proper coding.

As well, what exactly are you going to do when you catch an exception telling you that you forgot to override a method? Display a message to the user?

Error!
The software you are using was written by someone who cannot follow instructions. Please terminate the program for your own safety.

My take is that unanticipated errors due to programmer mistakes cannot be handled in code; they should be logged so you find them during development.

[marc weber]

Originally posted by David Harkness:
I've always felt the exact opposite.

You are correct. I had it backwards.

[Ilja Preuss]

Originally posted by David Harkness:
Of course, that's precisely the point. When the method is optional, I use the UnsupportedOperationException route instead of making it abstract.

I do that sometimes, too. Recently I begun to see it as a code smell. I prefer the objects not implementing that method actually not to have it at all.