• Post Reply Bookmark Topic Watch Topic
  • New Topic

Overriding methods of interface possible ?  RSS feed

 
Ranch Hand
Posts: 58
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ranchites,

I have this snippet of code in which one interface B overrides the methods in the interface A by extending the interface,How is it possible and what conclusion we have to arrive at from this overriding(I mean utility point of view )?

[ January 08, 2008: Message edited by: Shaan patil ]
 
lowercase baba
Bartender
Posts: 12565
49
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
let's say you sign a contract with me, saying "I will build a house on this piece of property".

Then, the next day, you sign a contract with Jim Yingst, saying that you will build a house on the same piece of property.

Then, you build a house there.

Which contract have you fulfilled?

both.

It's the same thing with an interface. "class foo implements bar" means that the class will have every method listed in the interface. if somehow the same method is 'listed' twice as something that has to be implemented, it's no big deal - as long as it IS implemented.
 
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I call dibs on the house.
 
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If a class implements two interfaces (related or not) that contain the same method, and both interfaces have the same specification for the method, then all is well. You just implement the method (once), and both interfaces are happy.

If a class tries to implement two interfaces that contain the same method but the two interfaces have different specifications for the method, you are in trouble. There is no way to tell "which version" of the method is being called. You must refactor your design.

It sounds bad, but in fact I have never come across a real example of this in my 10 years of Java.

The artificial example by which I was first made aware of this was: -

 
Shaan patil
Ranch Hand
Posts: 58
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
HI Ranchites,

Then the issue is not solved, So what is the solution ?


Regards
 
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Shaan patil:

Then the issue is not solved, So what is the solution ?


There is no "issue". The question is meaningless. The answer to your question is "both".
 
Shaan patil
Ranch Hand
Posts: 58
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ernest Friedman-Hill ,


Thanks for the respones !!!
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you are simultaneously asked to do something by two different people, sometimes it's possible and sometimes it isn't. It depends on what you're being asked to do. Sometimes both people ask for the exact same thing. Other times they ask for different things, but you can do both. Other times there is no way to do both things that are being asked of you. It all depends on what the requirements are.

If you're overriding one Java method with another (whether in a class or interface doesn't matter right now), then there are four possibilities:

1: The contracts for the two methods are identical.

2: The contracts for the two methods are different but compatible.

3: The contracts for the two methods are incompatible, though the code can still compile.

4: The method declarations are so incompatible that the code can't even compile.

Fred's example with building a house is like the first case. Peter's example is like the third case - it compiles, but it can't possibly do what the javadoc says it does.

For an example of the second case, look at Collection.iterator() and [url=]List.iterator()[/url], for example. The Collection method says "There are no guarantees concerning the order in which the elements are returned (unless this collection is an instance of some class that provides a guarantee)." The overriding method in List says "Returns an iterator over the elements in this list in proper sequence." The second contract is different from the first, but that's OK - the first contract allows other methods to override it with more specific behavior. So the iterator for a Collection isn't necessarily in any particular order - but if the Collection is a List, then the iterator will give you the elements in the order of the list. The overriding method is giving more specific behavior, which is allowed by the base method.

For an example of the fourth case, just change the return type on the overriding method. Or have it throw a new checked exception that isn't allowed by the base method. In these cases, the contract doesn't even matter - the compiler won't let you perform the override at all.
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jim Yingst:
The overriding method in List says...


The method in List hides, not overrides, the method in Collection. Overriding only happens in implementations of instance methods, not in declarations of methods in interfaces.

(Jim - I'm sure you know, but this is for the thread. It seemed worth picking you up on it, because this thread is about exactly that issue.)
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Apologies to the original poster since this was posted in "Beginner". But:

I disagree. Overriding happens with instance methods, while hiding happens with class methods. Whether they are methods in interfaces or classes is immaterial to this definition. See JLS 9.4.1.

The key difference is that with hiding there would still be a way to access the hidden method, by using the superclass name. With overriding, the new method declaration completely replaces the old one, and there is no way to call the overridden method instead of the overriding method (using an instance of the overriding subclass). With an interface, even though the actual implementation of the method has not been provided yet, it's still guaranteed that when it eventually is provided by a concrete class that implements the subinterface, the new implementation will completely replace the old one, for all instances of the overriding subclass. And there will be no way for those subclass instances to access the overridden definition from the superclass, or in this case superinterface. Example:

[ January 09, 2008: Message edited by: Jim Yingst ]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!