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 ?

Brannan

In the first case the coder of class C does not need to know the detail that B inherits A, he just needs to read the documentation for B. – Smoothtongued

@Brannan consider selecting a 'best answer' – Sublieutenant

Answer 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.

Repudiate

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

Answer 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.

Ankylosis

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. – Ewell

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. – Ankylosis

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. – Ewell

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. – Ankylosis

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. – Ankylosis

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? – Ewell

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. – Ankylosis

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). – Ankylosis

Answer 3

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

Maighdiln

That's the real reason why you extend an interface. If you want to implement a generic process that works on interfaces, you can't access both methods without casting. – Unstopped

Answer 4

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)

Lubric

Answer 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.

Bloomery

Answer 6

Sometimes, you wouldn't want to allow being B without being A, but want to allow being A without necessarily being B. If A is Car and B is SportCar, you might want to use just Car interface to handle some flows, but sometimes need to be more specific and use explicitly SportCar. This way, you cannot decide one day to implement just SportCar. It forces you to implement Car as well. That's exactly the meaning of inheritance in OOP.

Moreover, lets say you would want to declare a new class member implementing SportCar. How would you make it also implement Car interface? As far as I know, there is no way to add a type that consists of multiple interfaces.

public SportCar myCar;
// public SportCar,Car myCar -> invalid

This way you can't promise that myCar would have a method of Car (like Drive()), which looses the advantage that was gained from inheritance.

Bydgoszcz

Answer 7

What you are saying is right, but it's not just about getting our work done, what if the requirement is like this:

1) Imagine that there are 10 interfaces, not designed at the same time. For e.g. the AutoCloseable interface in Java 7. A new auto close feature was added, it was not there till Java 6.

2) If you designed an interface C which is a marker interface and you want all the classes derived from a given class B to be marked, the best solution would be to use B extends C and not going and putting the implements C everywhere.

There are many more reasons. If you look at the bigger picture of the classes and hierarchy, you might get the answer yourself.

Happy to Help Dharam

Pyo

Answer 8

The main difference here is that in your first example B is A and then some. That means Interface B calls method1() and method2(), where as in the second one A and B are separate (interface B DOES NOT conclude method1()) and class C implements A and B. In both intances Class C will override method1() and method2(). I hope this helps!

Unreeve