Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

force method to be overriden in subclasses  RSS feed

 
Tian Zhang
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:



then when extended:



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
Ranch Hand
Posts: 2409
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
if i append abstract to the method declaration i get a "abstract method not allowed in non-abstract class":



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
Ranch Hand
Posts: 2409
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Consider this as an example.





The only way that you can make an instance of MyNuClass is to override and implement numbers().
 
marc weber
Sheriff
Posts: 11343
Java Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ilja Preuss do you mean the following solution:


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
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Tian Zhang:
Ilja Preuss do you mean the following solution:



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
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 11343
Java Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
    Sheriff
    Posts: 11343
    Java Mac Safari
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by David Harkness:
    I've always felt the exact opposite.

    You are correct. I had it backwards.
     
    Ilja Preuss
    author
    Sheriff
    Posts: 14112
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    Don't get me started about those stupid light bulbs.
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!