Dlaczego interfejs nie może zaimplementować innego interfejsu?

Chodzi mi o to że:

interface B {...}

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

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

Wyszukałem w Google i znalazłem to :

implementsoznacza zdefiniowanie implementacji metod interfejsu. Jednak interfejsy nie mają implementacji, więc nie jest to możliwe.

Jednak interfejs jest w 100% klasą abstrakcyjną, a klasa abstrakcyjna może implementować interfejsy (w 100% klasa abstrakcyjna) bez implementowania swoich metod. Jaki jest problem, kiedy definiuje się jako „interfejs”?

W szczegółach,

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

implementsoznacza implementację, kiedy interfacema zadeklarować tylko dostarczyćinterface nie wykonania.

100% abstract classjest funkcjonalnym odpowiednikiem an, interfaceale może mieć również implementację, jeśli chcesz (w tym przypadku nie pozostanie 100%abstract ), więc z perspektywy JVM są to różne rzeczy.

Również zmienna składowa w klasie abstrakcyjnej 100% może mieć dowolny kwalifikator dostępu, podczas gdy w interfejsie są one niejawnie public static final .

implementsoznacza, że ​​zachowanie zostanie zdefiniowane dla abstractmetod (z wyjątkiem oczywiście klas abstrakcyjnych), definiujesz implementację.

extends oznacza, że ​​zachowanie jest dziedziczone.

W przypadku interfejsów można powiedzieć, że jeden interfejs powinien mieć takie samo zachowanie jak inny, nie ma nawet rzeczywistej implementacji. Dlatego bardziej sensowne jest używanie interfejsu do extendsinnego interfejsu, zamiast go implementować.

Na marginesie, pamiętaj, że nawet jeśli abstractklasa może definiować abstractmetody (rozsądny sposób, w jaki robi to interfejs), nadal jest klasą i nadal musi być dziedziczona (rozszerzana), a nie implementowana.

Koncepcyjnie istnieją dwie klasy „domen” i interfejsy. Wewnątrz tych domen, które zawsze rozszerzasz, tylko klasa implementuje interfejs, co jest swego rodzaju „przekraczaniem granicy”. Zatem zasadniczo „rozszerza” dla interfejsów odzwierciedla zachowanie klas. Przynajmniej myślę, że taka jest logika. Wygląda na to, że nie wszyscy zgadzają się z tego rodzaju logiką (sam uważam, że jest to trochę wymyślone) i tak naprawdę nie ma żadnego technicznego powodu, aby w ogóle mieć dwa różne słowa kluczowe.

Jednak interfejs jest w 100% klasą abstrakcyjną, a klasa abstrakcyjna może implementować interfejs (w 100% klasa abstrakcyjna) bez implementacji swoich metod. Jaki jest problem, kiedy definiuje się jako „interfejs”?

To jest po prostu kwestia konwencji. Twórcy języka java zdecydowali, że „rozszerza się” to najlepszy sposób na opisanie tej relacji, więc wszyscy tego używamy.

Ogólnie rzecz biorąc, nawet jeśli interfejs jest „klasą w 100% abstrakcyjną”, nie myślimy o nim w ten sposób. Zwykle myślimy o interfejsach jako o obietnicy implementacji pewnych kluczowych metod, a nie jako klasie, z której można wywodzić. Dlatego mamy tendencję do używania innego języka dla interfejsów niż dla klas.

Jak twierdzą inni, istnieją dobre powody, aby wybrać „rozciąga się” zamiast „narzędzi”.

Mam nadzieję, że pomoże ci to trochę to, czego nauczyłem się podczas studiów na uczelni oops (core java).

Implements oznacza zdefiniowanie implementacji metod interfejsu. Jednak interfejsy nie mają implementacji, więc nie jest to możliwe. Interfejs może jednak rozszerzać inny interfejs, co oznacza, że ​​może dodawać więcej metod i dziedziczyć jego typ.

Oto przykład poniżej, to jest moje zrozumienie i to, czego nauczyłem się w Ups.

interface ParentInterface{  
        void myMethod();  
}  

interface SubInterface extends ParentInterface{  
        void anotherMethod();  
}  

i miej na uwadze jeden interfejs może tylko rozszerzyć inny interfejs i jeśli chcesz zdefiniować jego funkcję w jakiejś klasie to tylko interfejs jest zaimplementowany np. poniżej

public interface Dog
{
    public boolean Barks();

    public boolean isGoldenRetriever();
}

Gdyby klasa miała zaimplementować ten interfejs, wyglądałby tak:

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

    }

    public boolean isGoldenRetriever{
    // method definition here
    }
}

a jeśli klasa abstrakcyjna ma jakąś abstrakcyjną funkcję zdefiniowaną i zadeklarowaną i chcesz zdefiniować te funkcje lub możesz powiedzieć, że zaimplementuj tę funkcję, to przypuszczasz, że rozszerzasz tę klasę, ponieważ klasa abstrakcyjna może być rozszerzana tylko. oto przykład poniżej.

public abstract class MyAbstractClass {

    public abstract void abstractMethod();
}

Oto przykład podklasy MyAbstractClass:

public class MySubClass extends MyAbstractClass {

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

Interfejs jest jak abstrakcja, która nie zapewnia żadnej funkcjonalności. Dlatego nie „wdraża”, ale rozszerza inne abstrakcje lub interfejsy.

Interface to klasa, która zawiera abstrakcyjną metodę, która nie może stworzyć żadnego obiektu. Ponieważ Interface nie może stworzyć obiektu i nie jest to czysta klasa, nie warto go implementować.