Ereditarietà multipla in Java. Confronto tra composizione ed ereditarietà

"Il problema dei diamanti"

package com.journaldev.inheritance;
public abstract class SuperClass {
   	public abstract void doSomething();
}

package com.journaldev.inheritance;
public class ClassA extends SuperClass{
    @Override
 public void doSomething(){
        System.out.println("Какая-то реализация класса A");
    }
  //собственный метод класса  ClassA
    public void methodA(){
    }
}

package com.journaldev.inheritance;
public class ClassC extends ClassA, ClassB{
    public void test(){
        //вызов метода родительского класса
        doSomething();
    }
}

Ereditarietà multipla e interfacce

package com.journaldev.inheritance;
public interface InterfaceA {

    public void doSomething();
}

package com.journaldev.inheritance;

public interface InterfaceB {

    public void doSomething();
}

package com.journaldev.inheritance;

public interface InterfaceC extends InterfaceA, InterfaceB {

    //метод, с тем же названием описан в  InterfaceA и InterfaceB
    public void doSomething();

package com.journaldev.inheritance;

public class InterfacesImpl implements InterfaceA, InterfaceB, InterfaceC {

    @Override
    public void doSomething() {
        System.out.println("doSomething реализация реального класса ");
    }

    public static void main(String[] args) {
        InterfaceA objA = new InterfacesImpl();
        InterfaceB objB = new InterfacesImpl();
        InterfaceC objC = new InterfacesImpl();

        //все вызываемые ниже методы получат одинаковую реализацию конкретного класса

        objA.doSomething();
        objB.doSomething();
        objC.doSomething();
    }
}

La composizione come salvezza

package com.journaldev.inheritance;

public class ClassC{

    ClassA objA = new ClassA();
    ClassB objB = new ClassB();

    public void test(){
        objA.doSomething();
    }

    public void methodA(){
        objA.methodA();
    }

    public void methodB(){
        objB.methodB();
    }
}

Composizione o eredità?

1. Supponiamo di avere la seguente combinazione di classi genitore-erede:

   ClassC.java

   package com.journaldev.inheritance;
   
   public class ClassC{
   
   public void methodC(){
     	}
   
   }

   ClassD.java

   package com.journaldev.inheritance;
   
   public class ClassD extends ClassC{
   
       public int test(){
           return 0;
       }
   }

   Il codice sopra viene compilato e funziona bene, ma cosa succederebbe se ClassCfosse implementato diversamente:

   package com.journaldev.inheritance;
   
   public class ClassC{
   
       public void methodC(){
       }
   
       public void test(){
       }
   }

   Tieni presente che il metodo test()esiste già nella classe discendente, ma restituisce un risultato di tipo diverso. Ora ClassD, se stai utilizzando un IDE, non verrà compilato. Ti verrà consigliato di modificare il tipo restituito nel discendente o nella superclasse.

   Ora immaginiamo una situazione in cui esiste un'ereditarietà multilivello delle classi e la superclasse non è disponibile per le nostre modifiche. Ora, per eliminare l'errore di compilazione, non abbiamo altra scelta che cambiare la firma o il nome del metodo della sottoclasse. Dovremo anche apportare modifiche a tutti i luoghi in cui è stato chiamato questo metodo. Pertanto, l’ereditarietà rende il nostro codice fragile.

   Il problema sopra descritto non si verifica mai nel caso della composizione, e rende quindi quest'ultima preferibile all'ereditarietà.

2. Il prossimo problema con l'ereditarietà è che esponiamo tutti i metodi del genitore al client. E se la superclasse non è progettata in modo molto corretto e contiene buchi di sicurezza. Quindi, anche se ci prendiamo la massima cura della sicurezza nell’implementazione della nostra sottoclasse, dipenderemo comunque dall’implementazione difettosa della classe genitore.

   La composizione ci aiuta a fornire un accesso controllato ai metodi di una superclasse, mentre l'ereditarietà non mantiene alcun controllo sui suoi metodi. Questo è anche uno dei principali vantaggi della composizione rispetto all’ereditarietà.

3. Un altro vantaggio della composizione è che aggiunge flessibilità quando si chiamano metodi. L'implementazione della classe ClassCsopra descritta non è ottimale e utilizza l'associazione anticipata al metodo chiamato. Modifiche minime ci consentiranno di rendere flessibile la chiamata del metodo e consentire l'associazione tardiva (associazione in fase di esecuzione).

   ClassC.java

   package com.journaldev.inheritance;
   public class ClassC{
       SuperClass obj = null;
       public ClassC(SuperClass o){
           this.obj = o;
       }
       public void test(){
           obj.doSomething();
       }
   
       public static void main(String args[]){
           ClassC obj1 = new ClassC(new ClassA());
           ClassC obj2 = new ClassC(new ClassB());
   
           obj1.test();
           obj2.test();
       }
   }

   Il programma sopra mostrerà:

   doSomething implementation of A
   doSomething implementation of B

   Questa flessibilità nella chiamata del metodo non si riscontra con l'ereditarietà, il che rende la composizione l'approccio migliore.

4. Il test unitario è più semplice nel caso della composizione perché sappiamo che per tutti i metodi che vengono utilizzati nella superclasse possiamo eseguire lo stub dei test, mentre nell'ereditarietà dipendiamo molto dalla superclasse e non sappiamo come funzionano i metodi della classe genitore sarà usato. Quindi, a causa dell'ereditarietà, dovremo testare tutti i metodi della superclasse, il che è un lavoro non necessario.

   Idealmente, l’ereditarietà dovrebbe essere utilizzata solo quando la relazione “ is-a ” è vera per le classi genitore e figlio, altrimenti si dovrebbe preferire la composizione.