Когда наследование интерфейса в Java полезно? - PullRequest
2 голосов
/ 04 ноября 2011

Давайте взглянем на следующий код в Java.

interface FirstInaterface
{
    public void show();
}

interface SecondInterface extends FirstInaterface
{
    @Override
    public void show();

    public void someConcreteMethod();
}

interface ThirdInterface extends SecondInterface
{
    @Override
    public void show();
}

final class Demo implements ThirdInterface
{
    @Override
    public void show()
    {
        System.out.println("The show() method invoked");
    }

    @Override
    public void someConcreteMethod()
    {
        System.out.println("The someConcreteMethod() method invoked");
    }

}

final public class Main
{
    public static void main(String[] args)
    {
        Demo demo=new Demo();
        demo.show();
        demo.someConcreteMethod();
    }
}

Приведенный выше код в Java демонстрирует многоуровневое наследование интерфейсов, в котором ThirdInterface имеет два интерфейса вышеЭто.Метод show () сначала переопределяется в интерфейсе SecondInaterface ahd, затем снова в интерфейсе ThirdInterface , и этот интерфейс наконец наследуется классом Demo .


В таком случае, какая версия методов show () из вышеуказанных интерфейсов будет включена в класс Demo?Как компилятор может динамически разрешать конкретную версию метода show () во время выполнения?


Мне кажется, что метод show () в последнем интерфейсе в вышеупомянутой иерархии наследования интерфейса (а именно ThirdInterface) будет вызываться компилятором.Если это так, то методы show () в вышеупомянутых двух интерфейсах (а именно, FirstInaterface, SecondInaterface) бесполезны и вообще не служат цели, так как они объявлены в интерфейсах, они сами могут никогда иметьих собственные реализации в любом месте.Когда такой вид наследования интерфейса полезен?

Ответы [ 5 ]

4 голосов
/ 04 ноября 2011

Только метод реализации могут переопределять, а не спецификации метода в интерфейсе.

В таком сценарии, какая версия методов show () из вышеуказанных интерфейсов будетвключены в класс Demo?Как компилятор может динамически разрешать конкретную версию метода show () во время выполнения?

Какие "версии"?Сигнатуры методов идентичны, поэтому на самом деле существует только одна спецификация метода.Во время выполнения будет класс реализации, и только реализация метода в этом классе будет фактически вызвана.

Если это так, то методы show () в двух вышеупомянутых интерфейсах (а именно, FirstInaterface, SecondInaterface) бесполезны и вообще не служат цели, поскольку они объявляются в интерфейсах, они сами никогда не могут иметь свои собственные реализации где-либо.* напрямую?Во всяком случае, то, что не имеет никакой (технической) цели, - это «переопределение» методов в дочерних интерфейсах.Если бы SecondInterface и ThirdInterface не имели метода show(), он имел бы точно такой же синтаксический эффект.

Однако может существовать веская причина для переопределения методов в дочернем интерфейсе: предоставитьдругой комментарий, объясняющий семантические изменения в методе контракта.Примеры для этого можно увидеть в структуре коллекций Java API: Set.add() имеет контракт, отличный от Collection.add(), так как он добавляет ограничение, что дублирующиеся элементы не должны добавляться.

1 голос
/ 04 ноября 2011

Единственное использование, которое я могу придумать при переопределении методов суперинтерфейса в подинтерфейсах, это документация. Таким образом, вы сразу видите, какие методы требует этот интерфейс, и вам не нужно проверять суперинтерфейсы для поиска дополнительных методов. Это также может иметь смысл, если вы хотите уточнить использование метода для этого подинтерфейса в отличие от использования в суперинтерфейсе или в других подинтерфейсах.

Для компилятора вообще нет разницы, переопределите ли вы эти методы или нет.

Конечно, если бы вы использовали языки AOP в качестве AspectJ, вы могли бы внедрить реализованный метод в интерфейс, и этот вопрос может стать актуальным. В этих случаях компилятор берет первую реализацию, которую он встречает в иерархии интерфейса, начиная с интерфейса, реализуемого вашим классом.

1 голос
/ 04 ноября 2011

Компилятор не выберет метод show() какого-либо интерфейса: он вызовет метод класса, вот и все. Интерфейсы просто говорят, что метод show должен быть реализован в классе.

Переопределение метода в интерфейсе бесполезно (кроме случаев, когда вы добавляете аннотации). Наследование интерфейса полезно только при добавлении методов.

1 голос
/ 04 ноября 2011

В таком случае, какая версия методов show () из вышеуказанных интерфейсов будет включена в класс Demo?Как компилятор может динамически разрешать определенную версию метода show () во время выполнения?

 Demo demo=new Demo();

showMethod() объекта будет вызвано.Итак, здесь объект класса Demo, поэтому его версия будет принята.

также во время компиляции Demo класс должен иметь объявление метода show и someConcreteMethod, иначе он превратится в ошибку времени компиляции


Я чувствую, что метод show () в последнем интерфейсе в приведенной выше иерархии наследования интерфейса (а именно ThirdInterface) будет вызываться компилятором

В интерфейсе вы фактически не можете обеспечить реализацию


Если это так, то методы show () в двух вышеупомянутых интерфейсах (а именно, FirstInaterface, SecondInaterface) бесполезны и не имеют никакой цели, так как ониобъявленные в интерфейсах, они сами никогда не могут иметь своих собственных реализаций.Когда такой вид наследования интерфейса полезен?

Да, это просто объявление .. и оно неявно наследуется от родительского интерфейса.так что, если вы напишите или нет, это не имеет никакого значения

0 голосов
/ 04 ноября 2011

метод show() для Demo будет вызван, потому что когда вы пишете Demo demo=new Demo();, тогда во время выполнения JVM запускает метод из класса .... интерфейс просто контракт .... они не могут дать реализацию
если вы не переопределите show(); and someConcrete(), то это покажет ошибку времени компиляции ...

When such kind of interface inheritance is useful?   

этот тип реализации используется полностью из-за способности повторного использования, что означает, что в первом интерфейсе есть некоторое поведение, какое-то в 2-м, что-то в 3-м ... и если вам нужен класс, который имеет все эти функции и некоторые дополнительные, тогда 2 пути ..
1. сделать другой интерфейс, имеющий все эти функции. Или
2. создайте интерфейс и ингарируйте его через те интерфейсы, которые имеют некоторую функциональность и добавляют немного дополнительного в ваш интерфейс.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...