• Post Reply Bookmark Topic Watch Topic
  • New Topic

Ambiguity when implementing multiple interfaces with same method / variable names  RSS feed

 
Bora Sabrioglu
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey folks,

imagine you are implementing 2 interfaces having identical method signatures:



How can I implement both methods?


Or another example with member variables:



How can I go about making clear which 'i' is meant?


Thanks in advance.
 
Joe Harry
Ranch Hand
Posts: 10128
3
Eclipse IDE Mac PPC Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is a clear conflict with respect to inheritance. It effectively means that for the compiler, there is only one method which is visible in the scope of your class implementing both the interfaces.

Have a look at the JLS http://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2
 
Paul Clapham
Sheriff
Posts: 22819
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bora Sabrioglu wrote:How can I implement both methods?


There aren't any "both" methods. There's only one method, named doStuff(), which is specified by both interfaces. And your posted code does implement it correctly. If your design requires different implementations of the doStuff() method for the two interfaces then you've got a problem, because you can only have one implementation.

How can I go about making clear which 'i' is meant?


Well, in those interfaces the variable 'i' is a static variable (as it must be to be declared in an interface). Since it's static, you don't need an instance of the class to use it. So the simplest way of making clear which 'i' is meant is like this:



Note that your posted code in this example doesn't compile, because 'i' is ambiguous -- as both you and the compiler point out.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66304
152
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And, of course, you'd never really purposefully do that, right?
 
Bora Sabrioglu
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was just wondering how it works in Java, since I read in HFJ about the "deadly diamond of death" in C++ and how Java goes about solving this. So I thought that if multiple inheritance in Java is forbidden for classes but allowed for interfaces, then what if one interface inherits from many interfaces and one class implements this interface... or as in the example above, implements multiple interfaces directly... then this would be a different form of the DDoD-problem I thought... but as you pointed out, the compiler stops one from doing this and there is no room for ambiguity.

I of course would not go about implementing such interfaces myself, but could imagine that both interfaces are from different external and independent sources... then there you would have one implementation for both interfaces.
 
Dave Tolls
Ranch Foreman
Posts: 3056
37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The problem with the C++ diamond of death is when you inherit from two classes that have the same method signature, including implementations.
The problem there is, which implementation to use.

As said earlier, Java doesn't have this problem as there is only going to be the one implementation.
 
Darryl Burke
Bartender
Posts: 5167
11
Java Netbeans IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dave Tolls wrote:Java doesn't have this problem as there is only going to be the one implementation.

Not any more, with Java 8 allowing interfaces to have default methods.
 
Dave Tolls
Ranch Foreman
Posts: 3056
37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Darryl Burke wrote:
Dave Tolls wrote:Java doesn't have this problem as there is only going to be the one implementation.

Not any more, with Java 8 allowing interfaces to have default methods.


...bum...

So how do they get round the problems C++ had?
Haven't got 8 here, so can't cobble together a test.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dave Tolls wrote:The problem there is, which implementation to use.
As said earlier, Java doesn't have this problem as there is only going to be the one implementation.

Not quite true since, as you've already discovered, Java does allow multiple inheritance with interfaces.

The solution - as Bear hinted at - is not to let it happen.

An ounce of prevention is worth a pound of cure.

Winston
 
Darryl Burke
Bartender
Posts: 5167
11
Java Netbeans IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dave Tolls wrote:So how do they get round the problems C++ had?
Haven't got 8 here, so can't cobble together a test.

I don't rightly know, but I was playing with Java 8 for something I'm working on for personal use, and this functioned as I hoped it would. Note that I'm typing the relevant code here, so there may be typos or other bloopers. I'm also not following formatting conventions, in the interest of brevity.

Since all three methods are inherited via each of the interfaces implements, MemberSpouseChild inherits default, not-overridden implementations from Person as well as three separate overrides from each of the 3 interfaces. However, tests showed that an instance of MemberSpouseChild returned true for all the 3 methods.

It's another matter that I added those methods to have an alternative to testing instanceof.
 
Dave Tolls
Ranch Foreman
Posts: 3056
37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:
An ounce of prevention is worth a pound of cure.

Winston


And that worked so well 15+ years ago...;)

Darryl: Thanks for that, but now try it with unrelated interfaces. Because I can see how your structure would be valid, as I don't see the diamond there.
This cannot (can it?) be valid:

I would hope the compiler would throw it out (I can see how it would).
So I've possibly answered my own question.
 
Campbell Ritchie
Marshal
Posts: 56525
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It does throw it out. It complains about the absence of () after the method names


As you thought, it still won't compile when you correct that, because, “class MyThing inherits unrelated defaults for print() from types Something and SomethingElse”
 
Darryl Burke
Bartender
Posts: 5167
11
Java Netbeans IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dave Tolls wrote:Because I can see how your structure would be valid, as I don't see the diamond there.


I may be wrong (I'm not a programmer) but this looks like (double) diamond inheritance to me.
 
Dave Tolls
Ranch Foreman
Posts: 3056
37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:It does throw it out. It complains about the absence of () after the method names


Ha!
That always happens when I don't test things out.
In my defence, I couldn't test things out here.


Campbell Ritchie wrote:
As you thought, it still won't compile when you correct that, because, “class MyThing inherits unrelated defaults for print() from types Something and SomethingElse”


Good oh, I hoped it would (and couldn't actually see it not).


Darryl Burke wrote:
Dave Tolls wrote:Because I can see how your structure would be valid, as I don't see the diamond there.


I may be wrong (I'm not a programmer) but this looks like (double) diamond inheritance to me.

Not quite.
It's more:

Each method is only inherited down a single path.
If Spouse also over-rode isMember() then I would expect the compiler to complain as it couldn't tell which method to pick.
With the above there isn't actually that confusion.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dave Tolls wrote:Each method is only inherited down a single path...

Just noticed this (been away for a week or so), and I'm not sure I like it, because it's basically just a procedural implementation of a type check that could be done just as easily (and possibly more clearly) with instanceof or getClass().

I suspect also that it's redundant (although I have to admit that I haven't read the entire thread), because whatever it is that is dependant on those type checks can probably be made polymorphic.

You might be interested in reading this article, because those methods definitely look like "ask" methods to me - although admittedly, since Java is statically-typed, it's less of an issue for this sort of thing; just clumsy, IMO.

HIH

Winston
 
Dave Tolls
Ranch Foreman
Posts: 3056
37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:
Dave Tolls wrote:Each method is only inherited down a single path...

Just noticed this (been away for a week or so), and I'm not sure I like it, because it's basically just a procedural implementation of a type check that could be done just as easily (and possibly more clearly) with instanceof or getClass().

I suspect also that it's redundant (although I have to admit that I haven't read the entire thread), because whatever it is that is dependant on those type checks can probably be made polymorphic.

You might be interested in reading this article, because those methods definitely look like "ask" methods to me - although admittedly, since Java is statically-typed, it's less of an issue for this sort of thing; just clumsy, IMO.

HIH

Winston


Oh believe me, I'm not advocating that structure.
Just bouncing off Darryl's quick and dirty example of diamond inheritance.
And, reading it again myself, he was right and that is an example of a diamond inheritance, just not one that shows the problem with it...
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!