具有相同方法签名的两个接口在Java类中实现

Question

I have two Java interfaces and one implementing class.

(I have used Eclipse to run the program directly, and I did not try to check any compiler warning et cetera by explicitly compiling from the command line.)

Why do they run without problem? Why does Java allow this, even when it satisfies the "contract" of both interfaces but create ambiguity in implementing class?

Updated the example.

public interface CassettePlayer {
    void play();
}

public interface DVDPlayer {
    void play();
}

public class CarPlayer implements CassettePlayer,DVDPlayer{

    @Override
    public void play() {
        System.out.println("This plays DVD, screw you Cassette !");
    }

    public static void main(String args[]) {
        CarPlayer cp = new CarPlayer();
        cp.play();

        CassettePlayer firstInterface = new CarPlayer();
        firstInterface.play();

        DVDPlayer secondInterface = new CarPlayer();
        secondInterface.play();
    }
}

Answer 1

This scenario specifically allowed in the Java Language Specification, section 8.1.5 :

It is permitted for a single method declaration in a class to implement methods of more than one superinterface. For example, in the code:

 interface Fish { int getNumberOfScales(); } interface Piano { int getNumberOfScales(); } class Tuna implements Fish, Piano { // You can tune a piano, but can you tuna fish? int getNumberOfScales() { return 91; } } 

the method getNumberOfScales in class Tuna has a name, signature, and return type that matches the method declared in interface Fish and also matches the method declared in interface Piano ; it is considered to implement both.

The text then goes on to note that if the method signatures had different return types, such as double and int , there would be no way to implement both interfaces in the same class and a compile time error would be produced.

Answer 2

For this issue it's necessary to understand what interfaces are for.

An interface is a kind of "contract" so that one knows which methods are compulsorily implemented in a Class with that interface.

So if you need a Class implementing "DVDPlayer" (because you need the method "play()"), you'll find CarPlayer. Same goes for the need of a Class implementing CassettePlayer. That's the technical explanation.

But of course in your semantic coding you should ensure that CarPlayer's method "play()" satisfies the semantics of both DVDPlayer and CassettePlayer. I think in a practical application it will be a bad practice.

Of course in your example it's a bad idea to have two interfaces declaring the same method. More practically, you should have made an interface "Player" with method "play()" and have two other, more specific interfaces DVDPlayer and CassettePlayer (with specific methods for DVDs and cassettes) who inherit from Player. On the onther hand, if you don't need specific methods for DVDs or cassettes, then you don't need two different interfaces only implementing one and the same method - just use one interface Player, that'll be enough.

Answer 3

In this situation, there is no issue because both interfaces have same method signature. But What about this ?

interface Animal {
    public void eat() throws IOException;
}

interface Plants {
    public void eat() throws NullPointerException;
}

Which one is choosen by the compiler ? Why does it get error below code ?

public class Test implements Animal, Plants {

    public void eat() throws IOException {

    }
}

Compiler says : Exception IOException is not compatible with throws clause in Plants.eat()

Answer 4

The following page contains an example of a class that implements two interfaces that have the

1) same variable name 2) same method in each interface.

http://www.j2eeonline.com/java-tm-fundamentals-II/module2/interface-ambiguous-fields.jsp

Answer 5

没有冲突，因为它们都指定了相同的契约，实现类只提供了一个通过任一接口引用时调用的方法。

Answer 6

Why not? The class is satisfying the contracts defined by both interfaces.

Answer 7

The class implements both interfaces - so no issue. Of course, this sort of thing should be avoided in more complex scenarios where unintended behaviour might result.