Dziedziczenie wielokrotne w języku Java

Próbując w pełni zrozumieć, jak rozwiązać wiele problemów z dziedziczeniem w Javie, mam klasyczne pytanie, które muszę wyjaśnić.

Powiedzmy mam klasę Animalto ma sub klas Birdi Horsei muszę dokonać klasy Pegasus, która rozciąga się od Birda Horseponieważ Pegasusjest zarówno ptaków i koń.

Myślę, że to klasyczny problem z diamentami. Z tego co rozumiem, klasyczny sposób, aby rozwiązać ten jest aby Animal, Birdi Horsećwiczenia interfejsy i wdrożenie Pegasusod nich.

Zastanawiałem się, czy istnieje inny sposób rozwiązania problemu, w którym nadal mogę tworzyć obiekty dla ptaków i koni. Gdyby istniał sposób na stworzenie zwierząt, byłoby to świetne, ale niekonieczne.

Mógłbyś stworzyć interfejsy dla klas zwierząt (klasa w znaczeniu biologicznym), na przykład public interface Equidaedla koni i public interface Avialaeptaków (nie jestem biologiem, więc terminy mogą być błędne).

Wtedy nadal możesz utworzyć plik

public class Bird implements Avialae {
}

i

public class Horse implements Equidae {}

i również

public class Pegasus implements Avialae, Equidae {}

Dodawanie z komentarzy:

Aby zmniejszyć liczbę duplikatów kodu, możesz utworzyć klasę abstrakcyjną zawierającą większość wspólnego kodu zwierząt, które chcesz zaimplementować.

public abstract class AbstractHorse implements Equidae {}

public class Horse extends AbstractHorse {}

public class Pegasus extends AbstractHorse implements Avialae {}

Aktualizacja

Chciałbym dodać jeszcze jeden szczegół. Jak zauważa Brian , jest to coś, o czym OP już wiedział.

Pragnę jednak podkreślić, że proponuję ominąć problem „wielokrotnego dziedziczenia” z interfejsami i nie polecam używania interfejsów, które reprezentują już konkretny typ (np. Bird), a raczej zachowanie (inne odnoszą się do typowanie kaczek, co też jest dobre, ale mam na myśli tylko biologiczną klasę ptaków, Avialae). Nie polecam również używania nazw interfejsów zaczynających się od dużej litery „I”, takich jakIBird , co nie mówi nic o tym, dlaczego potrzebny jest interfejs. Na tym polega różnica w pytaniu: skonstruuj hierarchię dziedziczenia za pomocą interfejsów, użyj klas abstrakcyjnych, gdy jest to przydatne, zaimplementuj konkretne klasy w razie potrzeby i użyj delegowania, jeśli to konieczne.

Istnieją dwa podstawowe podejścia do łączenia obiektów razem:

• Pierwsza to dziedziczenie . Ponieważ już zidentyfikowałeś ograniczenia dziedziczenia, oznacza to, że nie możesz tutaj zrobić tego, czego potrzebujesz.
• Drugi to kompozycja . Ponieważ dziedziczenie nie powiodło się, musisz użyć kompozycji.

Sposób, w jaki to działa, polega na tym, że masz obiekt Animal. W ramach tego obiektu dodajesz następnie kolejne obiekty, które nadają wymagane właściwości i zachowania.

Na przykład:

• Bird rozszerza Animal wdraża IFlier
• Horse rozszerza narzędzia Animal IHerbivore, IQuadruped
• Pegasus rozszerza Animal implementuje IHerbivore, IQuadruped, IFlier

Teraz IFlierwygląda to tak:

 interface IFlier {
     Flier getFlier();
 }

BirdWygląda więc tak:

 class Bird extends Animal implements IFlier {
      Flier flier = new Flier();
      public Flier getFlier() { return flier; }
 }

Teraz masz wszystkie zalety dziedziczenia. Możesz ponownie użyć kodu. Możesz mieć kolekcję IFliers i możesz wykorzystać wszystkie inne zalety polimorfizmu itp.

Jednak masz również pełną elastyczność dzięki kompozycji. Możesz zastosować dowolną liczbę różnych interfejsów i kompozytowych klas podkładowych do każdego typuAnimal - z taką samą kontrolą, jaką potrzebujesz, nad konfiguracją każdego bitu.

Strategia Pattern alternatywne podejście do kompozycji

Alternatywnym podejściem w zależności od tego, co i jak robisz, jest posiadanie Animalklasy bazowej zawierającej kolekcję wewnętrzną, aby zachować listę różnych zachowań. W takim przypadku używasz czegoś bliższego Wzorcowi Strategii. To daje korzyści pod względem uproszczenia kodu (na przykład Horsenie trzeba nic wiedzieć o Quadrupedlub Herbivore), ale jeśli nie zastosujesz również podejścia interfejsu, stracisz wiele zalet polimorfizmu itp.

Mam głupi pomysł:

public class Pegasus {
    private Horse horseFeatures; 
    private Bird birdFeatures; 

   public Pegasus(Horse horse, Bird bird) {
     this.horseFeatures = horse;
     this.birdFeatures = bird;
   }

  public void jump() {
    horseFeatures.jump();
  }

  public void fly() {
    birdFeatures.fly();
  }
}

Czy mogę zasugerować koncepcję pisania na klawiaturze ?

Najprawdopodobniej miałbyś tendencję do rozszerzania interfejsu typu Bird and a Horse na Pegaza, ale pisanie typu kaczego sugeruje, że powinieneś raczej dziedziczyć zachowanie . Jak już wspomniano w komentarzach, pegaz nie jest ptakiem, ale potrafi latać. Więc twój Pegaz powinien raczej dziedziczyć Flyable-interface i powiedzmy Gallopable-interface.

Ten rodzaj koncepcji jest używany we wzorcu strategii . Podany przykład pokazuje, jak w rzeczywistości a dziedziczy kaczka FlyBehavioura QuackBehaviouri nadal nie może być kaczki, np RubberDuck, który nie może latać. Mogliby również Duckrozszerzyć Birdklasę a, ale wtedy zrezygnowaliby z pewnej elastyczności, ponieważ każdy Duckmógłby latać, nawet biedni RubberDuck.

Technicznie rzecz biorąc, można rozszerzyć tylko jedną klasę naraz i zaimplementować wiele interfejsów, ale kładąc ręce na inżynierię oprogramowania, sugerowałbym raczej rozwiązanie specyficzne dla problemu, na które nie ma odpowiedzi. Nawiasem mówiąc, dobrą praktyką OO jest nie rozszerzanie konkretnych klas / tylko rozszerzanie klas abstrakcyjnych, aby zapobiec niechcianemu zachowaniu dziedziczenia - nie ma czegoś takiego jak „zwierzę” i nie ma użycia obiektu zwierzęcego, a jedynie konkretne zwierzęta.

W Javie 8, która jest nadal w fazie rozwoju od lutego 2014 r., Można użyć domyślnych metod, aby uzyskać coś w rodzaju C ++ - jak wielokrotne dziedziczenie. Możesz również rzucić okiem na ten samouczek, który pokazuje kilka przykładów, z którymi łatwiej jest rozpocząć pracę niż oficjalna dokumentacja.

Trzymanie konia w stajni z półdrzwiami jest bezpieczne, ponieważ koń nie może przejść przez półdrzwi. Dlatego założyłem usługę zakwaterowania koni, która przyjmuje dowolny przedmiot typu koń i umieszcza go w stajni z półdrzwiami.

Czy więc koń jest jak zwierzę, które potrafi latać nawet koń?

Kiedyś dużo myślałem o dziedziczeniu wielokrotnym, ale teraz, gdy programuję od ponad 15 lat, nie obchodzi mnie już wdrażanie wielokrotnego dziedziczenia.

Najczęściej, kiedy próbowałem poradzić sobie z projektem, który wskazywał na wielokrotne dziedziczenie, później przychodziłem do wiadomości, że tęskniłem za zrozumieniem domeny problemu.

LUB

Jeśli wygląda jak kaczka i kwacze jak kaczka, ale potrzebuje baterii, prawdopodobnie masz złą abstrakcję .

Java nie ma problemu z dziedziczeniem wielokrotnym, ponieważ nie ma dziedziczenia wielokrotnego. Jest to zgodne z projektem, aby rozwiązać rzeczywisty problem wielokrotnego dziedziczenia (problem z diamentami).

Istnieją różne strategie łagodzenia tego problemu. Najbardziej natychmiast osiągalnym jest obiekt Composite, który sugeruje Pavel (zasadniczo jak radzi sobie z tym C ++). Nie wiem, czy wielokrotne dziedziczenie przez linearyzację C3 (lub podobne) jest na kartach przyszłości Javy, ale wątpię w to.

Jeśli twoje pytanie jest akademickie, to poprawnym rozwiązaniem jest to, że Ptak i Koń są bardziej konkretne i fałszywe jest założenie, że Pegaz to po prostu ptak i koń razem wzięci. Bardziej poprawne byłoby stwierdzenie, że Pegaz ma pewne nieodłączne właściwości wspólne z Ptakami i Koniami (to znaczy, że mogą mieć wspólnych przodków). Można to wystarczająco modelować, jak wskazuje odpowiedź Moritza.

Myślę, że to zależy w dużej mierze od twoich potrzeb i tego, jak twoje klasy zwierząt mają być użyte w twoim kodzie.

Jeśli chcesz mieć możliwość korzystania z metod i funkcji implementacji Horse i Bird w klasie Pegasus, możesz zaimplementować Pegaza jako kompozycję Bird and a Horse:

public class Animals {

    public interface Animal{
        public int getNumberOfLegs();
        public boolean canFly();
        public boolean canBeRidden();
    }

    public interface Bird extends Animal{
        public void doSomeBirdThing();
    }
    public interface Horse extends Animal{
        public void doSomeHorseThing();
    }
    public interface Pegasus extends Bird,Horse{

    }

    public abstract class AnimalImpl implements Animal{
        private final int numberOfLegs;

        public AnimalImpl(int numberOfLegs) {
            super();
            this.numberOfLegs = numberOfLegs;
        }

        @Override
        public int getNumberOfLegs() {
            return numberOfLegs;
        }
    }

    public class BirdImpl extends AnimalImpl implements Bird{

        public BirdImpl() {
            super(2);
        }

        @Override
        public boolean canFly() {
            return true;
        }

        @Override
        public boolean canBeRidden() {
            return false;
        }

        @Override
        public void doSomeBirdThing() {
            System.out.println("doing some bird thing...");
        }

    }

    public class HorseImpl extends AnimalImpl implements Horse{

        public HorseImpl() {
            super(4);
        }

        @Override
        public boolean canFly() {
            return false;
        }

        @Override
        public boolean canBeRidden() {
            return true;
        }

        @Override
        public void doSomeHorseThing() {
            System.out.println("doing some horse thing...");
        }

    }

    public class PegasusImpl implements Pegasus{

        private final Horse horse = new HorseImpl();
        private final Bird bird = new BirdImpl();


        @Override
        public void doSomeBirdThing() {
            bird.doSomeBirdThing();
        }

        @Override
        public int getNumberOfLegs() {
            return horse.getNumberOfLegs();
        }

        @Override
        public void doSomeHorseThing() {
            horse.doSomeHorseThing();
        }


        @Override
        public boolean canFly() {
            return true;
        }

        @Override
        public boolean canBeRidden() {
            return true;
        }
    }
}

Inną możliwością jest użycie systemu jednostka-składnik zamiast dziedziczenia do definiowania zwierząt. Oczywiście oznacza to, że nie będziesz mieć indywidualnych klas Java zwierząt, ale zamiast tego będą one definiowane tylko przez ich komponenty.

Niektóre pseudokody dla podejścia Entity-Component-System mogą wyglądać następująco:

public void createHorse(Entity entity){
    entity.setComponent(NUMER_OF_LEGS, 4);
    entity.setComponent(CAN_FLY, false);
    entity.setComponent(CAN_BE_RIDDEN, true);
    entity.setComponent(SOME_HORSE_FUNCTIONALITY, new HorseFunction());
}

public void createBird(Entity entity){
    entity.setComponent(NUMER_OF_LEGS, 2);
    entity.setComponent(CAN_FLY, true);
    entity.setComponent(CAN_BE_RIDDEN, false);
    entity.setComponent(SOME_BIRD_FUNCTIONALITY, new BirdFunction());
}

public void createPegasus(Entity entity){
    createHorse(entity);
    createBird(entity);
    entity.setComponent(CAN_BE_RIDDEN, true);
}

możesz mieć hierarchię interfejsów, a następnie rozszerzać swoje klasy z wybranych interfejsów:

public interface IAnimal {
}

public interface IBird implements IAnimal {
}

public  interface IHorse implements IAnimal {
}

public interface IPegasus implements IBird,IHorse{
}

a następnie zdefiniuj swoje klasy zgodnie z potrzebami, rozszerzając określony interfejs:

public class Bird implements IBird {
}

public class Horse implements IHorse{
}

public class Pegasus implements IPegasus {
}

Ehm, twoja klasa może być podklasą tylko dla 1 innej, ale nadal możesz mieć zaimplementowanych tyle interfejsów, ile chcesz.

Pegaz to w rzeczywistości koń (jest to szczególny przypadek konia), który potrafi latać (co jest „umiejętnością” tego specjalnego konia). Z drugiej strony można powiedzieć, że Pegaz to ptak, który potrafi chodzić i jest czteronożny - wszystko zależy od tego, jak łatwiej będzie Ci napisać kod.

Tak jak w Twoim przypadku możesz powiedzieć:

abstract class Animal {
   private Integer hp = 0; 
   public void eat() { 
      hp++; 
   }
}
interface AirCompatible { 
   public void fly(); 
}
class Bird extends Animal implements AirCompatible { 
   @Override
   public void fly() {  
       //Do something useful
   }
} 
class Horse extends Animal {
   @Override
   public void eat() { 
      hp+=2; 
   }

}
class Pegasus extends Horse implements AirCompatible {
   //now every time when your Pegasus eats, will receive +2 hp  
   @Override
   public void fly() {  
       //Do something useful
   }
}

Interfejsy nie symulują wielokrotnego dziedziczenia. Twórcy Javy uważali, że wielokrotne dziedziczenie jest błędne, więc w Javie nie ma czegoś takiego.

Jeśli chcesz połączyć funkcjonalność dwóch klas w jedną - skorzystaj z kompozycji obiektów. To znaczy

public class Main {
    private Component1 component1 = new Component1();    
    private Component2 component2 = new Component2();
}

A jeśli chcesz ujawnić pewne metody, zdefiniuj je i pozwól im delegować wywołanie do odpowiedniego kontrolera.

Tutaj mogą się przydać interfejsy - jeśli Component1implementuje interfejs Interface1i Component2implementuje Interface2, możesz zdefiniować

class Main implements Interface1, Interface2

Abyś mógł używać obiektów zamiennie tam, gdzie pozwala na to kontekst.

Więc z mojego punktu widzenia nie możesz mieć problemu z diamentami.

Jak już wiesz, wielokrotne dziedziczenie klas w Javie nie jest możliwe, ale jest możliwe w przypadku interfejsów. Możesz również rozważyć użycie wzorca projektowego kompozycji.

Kilka lat temu napisałem bardzo obszerny artykuł o kompozycji ...

/codereview/14542/multiple-inheritance-and-composition-with-java-and-c-updated

1. Zdefiniuj interfejsy do definiowania możliwości. Możesz zdefiniować wiele interfejsów dla wielu możliwości. Te możliwości mogą być realizowane przez określone zwierzę lub ptaka .
2. Użyj dziedziczenia, aby ustanowić relacje między klasami, udostępniając niestatyczne i niepubliczne dane / metody.
3. Użyj wzoru Decorator_pattern, aby dynamicznie dodawać możliwości. Pozwoli to zmniejszyć liczbę klas i kombinacji dziedziczenia.

Spójrz na poniższy przykład, aby lepiej zrozumieć

Kiedy używać wzoru dekoratora?

Aby zmniejszyć złożoność i uprościć język, w Javie nie jest obsługiwane dziedziczenie wielokrotne.

Rozważmy scenariusz, w którym A, B i C to trzy klasy. Klasa C dziedziczy klasy A i B. Jeśli klasy A i B mają tę samą metodę i wywołujesz ją z obiektu klasy potomnej, wywołanie metody klasy A lub B będzie niejednoznaczne.

Ponieważ błędy czasu kompilacji są lepsze niż błędy czasu wykonania, java renderuje błąd czasu kompilacji, jeśli odziedziczysz 2 klasy. Więc niezależnie od tego, czy masz tę samą metodę, czy inną, teraz wystąpi błąd czasu kompilacji.

class A {  
    void msg() {
        System.out.println("From A");
    }  
}

class B {  
    void msg() {
        System.out.println("From B");
    }  
}

class C extends A,B { // suppose if this was possible
    public static void main(String[] args) {  
        C obj = new C();  
        obj.msg(); // which msg() method would be invoked?  
    }
} 

Do rozwiązania problemu wielokrotnego dziedziczenia w Javie używany jest → interfejs

J2EE (core JAVA) Uwagi Mr. KVR Strona 51

Dzień - 27

1. Interfejsy są zasadniczo używane do tworzenia typów danych zdefiniowanych przez użytkownika.
2. W odniesieniu do interfejsów możemy osiągnąć koncepcję wielokrotnego dziedziczenia.
3. Dzięki interfejsom możemy osiągnąć koncepcję polimorfizmu, dynamicznego wiązania, a tym samym możemy poprawić wydajność programu JAVA na zmianę przestrzeni pamięci i czasu wykonywania.

Interfejs to konstrukcja zawierająca zbiór czysto niezdefiniowanych metod lub interfejs to zbiór czysto abstrakcyjnych metod.

[…]

Dzień - 28:

Składnia-1 do ponownego wykorzystania funkcji interfejsów do klasy:

[abstract] class <clsname> implements <intf 1>,<intf 2>.........<intf n>
{
    variable declaration;
    method definition or declaration;
};

W powyższej składni clsname reprezentuje nazwę klasy, która dziedziczy cechy z 'n' liczby interfejsów. „Implements” to słowo kluczowe, które służy do dziedziczenia funkcji interfejsu (interfejsów) do klasy pochodnej.

[…]

Syntax-2 dziedziczenie „n” liczby interfejsów do innego interfejsu:

interface <intf 0 name> extends <intf 1>,<intf 2>.........<intf n>
{     
    variable declaration cum initialization;
    method declaration;
};

[…]

Składnia-3:

[abstract] class <derived class name> extends <base class name> implements <intf 1>,<intf 2>.........<intf n>
{
  variable declaration;
  method definition or declaration;
};