Почему интерфейс не может реализовать другой интерфейс?


104

Я имею в виду:

interface B {...}

interface A extends B {...} // allowed  

interface A implements B {...} // not allowed

Я погуглил и нашел это :

implementsобозначает определение реализации методов интерфейса. Однако интерфейсы не имеют реализации, поэтому это невозможно.

Однако интерфейс - это 100% абстрактный класс, а абстрактный класс может реализовывать интерфейсы (100% абстрактный класс) без реализации своих методов. В чем проблема, когда он определяется как «интерфейс»?

Подробно,

interface A {
    void methodA();
}

abstract class B implements A {} // we may not implement methodA() but allowed

class C extends B {
   void methodA(){}
} 

interface B implements A {} // not allowed. 
//however, interface B = %100 abstract class B

Ответы:


110

implementsозначает реализацию, когда interfaceподразумевается просто объявить, а interfaceне предоставить реализацию.

100% abstract classфункционально эквивалентно a, interfaceно при желании он также может иметь реализацию (в этом случае он не останется 100% abstract), поэтому с точки зрения JVM это разные вещи.

Также переменная-член в 100% абстрактном классе может иметь любой квалификатор доступа, где в интерфейсе они неявно public static final.


8
Начиная с Java 8, интерфейсы могут иметь методы по умолчанию, что делает их в этом отношении более похожими на абстрактные классы.
forresthopkinsa

4
Спасибо за последнее предложение!
Тао Чжан

24

implementsозначает, что поведение будет определено для abstractметодов (за исключением, очевидно, абстрактных классов), вы определяете реализацию.

extends означает, что поведение передается по наследству.

С интерфейсами можно сказать, что один интерфейс должен иметь то же поведение, что и другой, нет даже фактической реализации. Вот почему имеет больше смысла использовать интерфейс с extendsдругим интерфейсом, а не реализовывать его.


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


4

Концептуально существуют два «доменных» класса и интерфейса. Внутри этих доменов вы всегда расширяетесь, только класс реализует интерфейс, который является своего рода «переходом границы». Таким образом, в основном "extends" для интерфейсов отражает поведение классов. По крайней мере, я думаю, что это логика. Похоже, что не все согласны с такой логикой (я нахожу ее немного надуманной), и на самом деле нет никакой технической причины для использования двух разных ключевых слов.


Если «Y расширяет X» и не запечатан, то можно иметь другой тип «Z», который расширяет «Y». Это будет верно независимо от того, является ли X интерфейсом или классом. Если, однако, «W реализует X», то «V реализует W» невозможно. Тот факт, что «extends» можно «связать», а «реализовать» не может казаться веской причиной для использования разных ключевых слов.
supercat

2

Однако интерфейс - это 100% абстрактный класс, а абстрактный класс может реализовывать интерфейс (100% абстрактный класс) без реализации своих методов. В чем проблема, когда он определяется как «интерфейс»?

Это просто вопрос условности. Авторы языка java решили, что «extends» - лучший способ описать эти отношения, поэтому мы все это используем.

В общем, даже если интерфейс является «100% абстрактным классом», мы так не думаем о них. Обычно мы думаем об интерфейсах как об обещании реализовать определенные ключевые методы, а не как производный класс. И поэтому мы склонны использовать другой язык для интерфейсов, чем для классов.

Как утверждают другие, есть веские причины для выбора «расширяет», а не «орудия».


Да сэр. Это вопрос условности. Многие люди пытаются логически оправдать ограничения исходного языка Java Sun, когда это просто личная точка зрения. Если бы компилятор добавил интерфейсы «реализует», я думаю, те же люди тоже это оправдали бы. :-)
Little Santi

1

Надеюсь, это немного поможет вам в том, чему я научился в oops (core java) во время учебы в колледже.

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

Вот пример ниже, это мое понимание и то, что я узнал в упс.

interface ParentInterface{  
        void myMethod();  
}  

interface SubInterface extends ParentInterface{  
        void anotherMethod();  
}  

и имейте в виду, что один интерфейс может расширять только другой интерфейс, и если вы хотите определить его функцию в каком-то классе, тогда реализован только интерфейс, например, ниже

public interface Dog
{
    public boolean Barks();

    public boolean isGoldenRetriever();
}

Теперь, если бы класс реализовал этот интерфейс, он бы выглядел так:

public class SomeClass implements Dog
{
    public boolean Barks{
    // method definition here

    }

    public boolean isGoldenRetriever{
    // method definition here
    }
}

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

public abstract class MyAbstractClass {

    public abstract void abstractMethod();
}

Вот пример подкласса MyAbstractClass:

public class MySubClass extends MyAbstractClass {

    public void abstractMethod() {
        System.out.println("My method implementation");
    }
}

0

Интерфейс похож на абстракцию, не предоставляющую никакой функциональности. Следовательно, он не «реализует», а расширяет другие абстракции или интерфейсы.


-6

Интерфейс - это класс, который содержит абстрактный метод, который не может создать какой-либо объект. Поскольку интерфейс не может создать объект и это не чистый класс, его не стоит реализовывать.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.