-2

I was reading about the diamond problem in case of default interfaces, and the documentation says that if there is an interface A with default method m(), which is extended by two other interfaces B & C both having there own default method m(), and now suppose we have a class D that implements both B and C, then class D needs to have it's own implementation of the method m(), otherwise compiler will through exception.

interface A {
  default void m() {
    System.out.println("Interface A"); 
  }  
}

interface B extends A { 
  default void m() {
    System.out.println("Interface B"); 
  }
}

interface C extends A { 
  default void m() {
    System.out.println("Interface C"); 
  }
}

//allowed multiple inheritance when D gives
//it's own implementation of method m()
//else compilation error
class D implements  B, C { 
  public void m() {
    System.out.println("Class D"); 
  }
}

If we go by the same logic, then why JAVA hasn't resolved the diamond problem in case of classes as well, and may be then we could have extended more than one classes.

interface A {
  default void m() {
    System.out.println("Interface A"); 
  }  
}

class B implements A { 
  public void m() {
    System.out.println("Interface B"); 
  }
}

class C implements A { 
  public void m() {
    System.out.println("Interface C"); 
  }
}

//multiple inheritance not allowed even when D gives
//it's own implementation of method m()
//still getting compilation error
class D extends  B, C { 
  public void m() {
    System.out.println("Class D"); 
  }
}
N Sharma
  • 11
  • 2
  • Also, https://stackoverflow.com/questions/21824402/java-multiple-inheritance – Alfabravo Nov 16 '17 at 16:44
  • The question seems to suppose that multiple inheritance of implementation is an important feature that is lacking in Java. Certainly Java doesn't have that among its features, but that's an intentional design decision, not the result of a technical limitation. Moreover, the importance of multiple inheritance is by no means manifest. Composition should often be preferred over inheritance anyway, and I daresay it should almost always be preferred over multiple inheritance, even in C++ and other languages that support MI. – John Bollinger Nov 16 '17 at 17:05

1 Answers1

0

What do you expect to be the default behaviour when calling D.m().

Do you want that it invokes B.m() or C.m()? You just don't know.

You'd have to add a new logic which decides what method needs to be called which would exactly be the same as the current need to override.

Because of this uncertainty and not consistent behavior which clearly clashes with javas principles, you're not allowed to do that.

Lino
  • 19,604
  • 6
  • 47
  • 65
  • Yes, I understand that, but my question was when JAVA does allow implementing multiple default interfaces in case of diamond situation, by just simply adding implementation of method m() in class D, then why doesn't it allow me to extend multiple classes as well in the same way? I am specifically questioning about interfaces with default methods vs classes here. – N Sharma Nov 16 '17 at 16:59
  • @NSharma An interface defines behaviour but not the implementation. For example take the interface `Gun`. its implementations can vary vastly, a water pistol and an automatic rifle have not the same mechanism but are all in all a gun. A water pistol shoots water, a rifle rounds. – Lino Nov 16 '17 at 17:05
  • @Lino, nowadays, an interface may indeed define implementation, by way of default methods. This is what the OP is talking about. However, that is intended as a compatibility feature for supporting adding new methods to existing interfaces, not a general-purpose use case. – John Bollinger Nov 16 '17 at 17:07
  • @JohnBollinger, yes that was my point. If JAVA 8 can allow this to happen in case of interfaces with default methods, then it could have done the same for classes as well. Why not follow the same rule here? Any limitation due to which this could not have been followed in case of classes? – N Sharma Nov 16 '17 at 17:35
  • @NSharma, as I already commented on the question, this is not fundamentally a technical issue but rather an intentional design choice. – John Bollinger Nov 16 '17 at 18:03