• Post Reply Bookmark Topic Watch Topic
  • New Topic

interface implementation  RSS feed

 
Mahesh Barik
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
in cases where one class is implementing 2 interfaces and both the interfaces have same method signature
and our class is overriding the method
which version will be called?
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are multiple declarations of the method, but there's only one definition, so there is no ambiguity as to what gets called.
 
Campbell Ritchie
Marshal
Posts: 56522
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
overriding the method
But you don't override the method. All methods in an interface are empty and (implicitly or explicitly) abstract.
Overriding means to change the method from the superclass.
What you are doing is implementing the empty method. That is why you write "public class Foo implements Bar{}."
 
fred rosenberger
lowercase baba
Bartender
Posts: 12562
49
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
when you implement an interface, you are saying "i promise that in this class i am writing, i will put the code for the methods listed in these interfaces".

you then write the code for said methods. if two (or twelve) interfaces all declare the same method name/signiature, it doesn't matter. you implement it once and have satisfied that part of the contract for ALL the interfaces.

So, no matter how you reference the object, you will get YOUR one-and-only implementation of hte method.
 
manuel aldana
Ranch Hand
Posts: 308
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i think you mean with method signature the method name and the parameters, because implementing A and B at the same time would clash:

interface A{
void bla();
}

interface B{
String bla();
}

apart from that i think it is not quite correct to define interface methods solely by their signature. there is a lot of semantics behind it, e.g. what you input and what you get (see design by contract). that means, though your interface methods look identical they offer different semantics.

so if i was you i would go for some rename-method refactorings to avoid such a problem. or if the semantics are the same, i would try use move method to form new interface groupings.
[ August 16, 2006: Message edited by: manuel aldana ]
 
Mahesh Barik
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi Thanks for your response
does the same principle apply for abstract class too?
thanks
 
Joanne Neal
Rancher
Posts: 3742
16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No, because you can't extend two (abstract) classes.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But you can extend an abstract class and implement an interface which could get you right back in the same problem spot. Anybody else remember Judy Tenuta? It could happen!

Manuel's post was pretty profound. Make sure you got the points. If the two abstractions use the same signature but are documented or intended to do different things, you're in trouble. If they use the same signature for the very same meaning, maybe the method should be its own interface.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!