Java why interface extends interface

Question

I am wondering under what circumstances do we extend an interface from an interface? Because, for example

interface A{
    public void method1();
}
interface B extends A{
    public void method2();
}
class C implements B{
    @Override public void method1(){}
    @Override public void method2(){}
}

Isn't it equivalent to

interface A{
    public void method1();
}
interface B{
    public void method2();     
}
class C implements A, B{
    @Override public void method1(){}
    @Override public void method2(){}
}

Are there any significant reasons behind ?

Solution 1

The significant reasons depend entirely on what the interface is supposed to do.

If you have an interface Vehicle and an interface Drivable it stands to reason that all vehicles are drivable. Without interface inheritance every different kind of car class is going to require

class ChevyVolt implements Vehicle, Drivable
class FordEscort implements Vehicle, Drivable
class ToyotaPrius implements Vehicle, Drivable

and so on.

Like I said all vehicles are drivable so it's easier to just have:

class ChevyVolt implements Vehicle
class FordEscort implements Vehicle
class ToyotaPrius implements Vehicle

With Vehicle as follows:

interface Vehicle extends Drivable

And not have to think about it.

Solution 2

Yes there is: it's like inheritance anywhere else. If B is a specialization of A then it should be written that way. The second one indicates that the class just happens to implement 2 interfaces with no relationship between them.

From the end result standpoint you could just use multiple interfaces in place of handling a hierarchy (just as you could avoid using inherited behavior in a class hierarchy). This would leave information more scattered, however, and as (if not more) significantly it obfuscates the intent of the software model.

Solution 3

Yes, there is one big difference.

In your first example, your new interface B is defined to extend from A, so going forward, any class that implements B automatically implements A. Basically, you're telling the compiler "here's what it means to be an A, here's what it means to be a B, and oh, by the way, all B's are also A's!" That lets you say things like...

class C implements B {
    ... you implement all of the methods you need...
    ...blah...
    ...blah...
}
A myNewA = new C();

and that works fine.

But, in your second example, you don't declare B to extend A, so the code above wouldn't work. When you try to assign an instance of (the second kind of) C into a reference for A, it would complain, because you haven't told the complier that "all B's are really A's." (i.e. there is no relation between B and C)

Solution 4

there is only one comment in

interface A{
    public void method1();
}
interface B extends A{
    public void method2();
}
class C implements B{
    @Override public void method1(){}
    @Override public void method2(){}
}

if you declare A a = new C();

you CANNOT call method2(); because interface A knows nothing about elements in interface B even you implements methods in class C

Solution 5

If you don't want B to be implemented without implementing A you can make B extends A.

Example:

interface LivingThing{
public void eat();
}

interface Dog extends LivingThing{
public void Bark();
}

It is possible to be a livingThing without being a dog but it is not possible to be a dog without being a livingThing. So if it can bark it can also eat but the opposite is not always true.

View more solutions

Comments

[overexchange]

A & B are interfaces's. So, What does it mean when you say B is A. interface is discovered after concrete classes are designed. I feel extending interfaces comes out of the consequence of bad design. If you understand the meaning of inherit it does not make sense to inherit an interface. It make sense to inherit concrete class because they represent or show the nature of real world objects and you inherit that nature because SubType is also part of that nature. BTW, Can you give me an example in jdk on extending interfaces? i would like to analyse it.

[Matt Whipple]

Concrete classes correspond to implementations of "real world objects" while interfaces represent their contracts or define what exactly should be "shown". In general if you have a class hierarchy with specialization of contracts then a corresponding interface hierarchy may make quite a bit of sense. I'm not going to research examples for you but I'd wager the Collections API is full of them.

[overexchange]

So, when one says, public interface List extends Collection{} Do you mean, List is Iterable, Because List is Collection and Collection is Iterable? I think this is wrong. check this answer from oracle technician who knows the designers of collection. Basically my point is, It does not make sense to extend an interface from design perspective.

[Matt Whipple]

That thread covers a particular instance which you're generalizing ambitiously. The underlying discussion is about the limitation of Java's single implementation inheritance, which is the underpinning of this whole conversation and the reason why although extensions using abstract classes and approaches like Template Method should likely be preferred they cannot be universal. Scraping off a single layer and evaluating extending Iterable alone is more representative. I would certainly say interface hierarchies should not be deep.

[Matt Whipple]

I did. I said it's out of context and generalized. The answer does not say that extending interfaces is bad practice, only that when specializations imply particular functionality that can be consistently implemented they should be handled as such rather than needlessly shifting the responsibility to implementors. I'm not saying the practice should be blindly adopted, but you're saying it should be wholly avoided so it's more on you to respond to the Iterable comment.

[overexchange]

my question is, As you said, java collection is good example to understand about extending interfaces, so considering an example, public interface List extends Collection{} Do you mean, List is-a Iterable, Because List is-a Collection and Collection is-a Iterable?

[Matt Whipple]

There are likely others throughout the jdk also, collections just came quickly to mind. Here's another interface hierarchy: docs.oracle.com/javase/7/docs/api/java/util/concurrent/…. There are likely plenty more if you actually look so you'd have a lot to dispell before even getting to standard frameworks and libraries outside of the core platform.

[Matt Whipple]

To answer your last question, yes that would be why. The hierarchy can allow for client code which uses the weakest reference type possible which can then free other code to use more specific contracts or implementation types all while avoiding any type coupling (basically layered polymorphism).

[atiqkhaled]

Wouldn't it be good for fresher if you give Vehicle interface extends Drivable interface in coded block.