简体   繁体   中英

Java why interface extends interface

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?

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.

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.

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." (ie there is no relation between B and C )

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

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.

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.

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 eg 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

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!

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM