Ponieważ ten temat nie jest zamknięty, opublikuję tę odpowiedź, mam nadzieję, że pomoże to komuś zrozumieć, dlaczego java nie zezwala na wielokrotne dziedziczenie.
Rozważ następującą klasę:
public class Abc{
public void doSomething(){
}
}
W tym przypadku klasa Abc niczego nie rozszerza, prawda? Nie tak szybko, ta klasa niejawnie rozszerza klasę Object, klasę bazową, która pozwala wszystkim działać w Javie. Wszystko jest przedmiotem.
Jeśli spróbujesz użyć klasy powyżej zobaczysz, że Twój IDE pozwalają na stosowanie metod takich jak: equals(Object o), toString(), etc, ale nie deklarują te metody, wyszli z klasy bazowejObject
Możesz spróbować:
public class Abc extends String{
public void doSomething(){
}
}
To jest w porządku, ponieważ twoja klasa nie będzie niejawnie rozszerzać, Objectale będzie rozszerzać, Stringponieważ to powiedziałeś. Rozważ następującą zmianę:
public class Abc{
public void doSomething(){
}
@Override
public String toString(){
return "hello";
}
}
Teraz Twoja klasa zawsze będzie zwracać „hello”, jeśli wywołasz toString ().
Teraz wyobraź sobie następującą klasę:
public class Flyer{
public void makeFly(){
}
}
public class Bird extends Abc, Flyer{
public void doAnotherThing(){
}
}
Ponownie klasa Flyerniejawna rozszerza Object, który ma metodę toString(), każda klasa będzie miała tę metodę, ponieważ wszystkie one rozszerzają się Objectpośrednio, więc jeśli wywołasz toString()from Bird, z której toString()javy musiałby skorzystać? Od Abclub Flyer? Stanie się tak z każdą klasą, która próbuje rozszerzyć dwie lub więcej klas, aby uniknąć tego rodzaju „kolizji metod”, zbudowali ideę interfejsu , w zasadzie można by pomyśleć, że jest to klasa abstrakcyjna, która nie rozszerza Object w sposób pośredni . Ponieważ są abstrakcyjne , będą musiały zostać zaimplementowane przez klasę, która jest obiektem (nie możesz samodzielnie instancjonować interfejsu, muszą być zaimplementowane przez klasę), więc wszystko będzie nadal działać poprawnie.
Aby odróżnić klasy od interfejsów, słowo kluczowe implements zostało zarezerwowane tylko dla interfejsów.
Możesz zaimplementować dowolny interfejs w tej samej klasie, ponieważ domyślnie nic nie rozszerza (ale możesz utworzyć interfejs, który rozszerza inny interfejs, ale ponownie, interfejs „ojca” nie rozszerza Object ”), więc interfejs jest tylko interfejs i nie będą cierpieć z powodu " kolizji sygnatur metod ", jeśli to zrobią, kompilator wyśle ostrzeżenie i będziesz musiał tylko zmienić sygnaturę metody, aby to naprawić (podpis = nazwa metody + parametry + typ zwrotu) .
public interface Flyer{
public void makeFly(); // <- method without implementation
}
public class Bird extends Abc implements Flyer{
public void doAnotherThing(){
}
@Override
public void makeFly(){ // <- implementation of Flyer interface
}
// Flyer does not have toString() method or any method from class Object,
// no method signature collision will happen here
}