Herencia múltiple en Java. Comparación de composición y herencia.

"El problema del diamante"

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();
    }
}

Herencia múltiple e interfaces.

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 composición como salvación

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();
    }
}

¿Composición o herencia?

1. Supongamos que tenemos la siguiente combinación de clases de padre-heredero:

   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;
       }
   }

   El código anterior se compila y funciona bien, pero ¿y si ClassCse implementara de manera diferente?

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

   Tenga en cuenta que el método test()ya existe en la clase descendiente, pero devuelve un resultado de un tipo diferente. Ahora ClassD, en caso de que esté utilizando un IDE, no se compilará. Se le recomendará que cambie el tipo de devolución en la clase descendiente o superclase.

   Ahora imaginemos una situación en la que hay herencia de clases en varios niveles y la superclase no está disponible para nuestros cambios. Ahora, para deshacernos del error de compilación, no tenemos otra opción que cambiar la firma o el nombre del método de la subclase. También tendremos que realizar cambios en todos los lugares donde se llamó a este método. Por tanto, la herencia hace que nuestro código sea frágil.

   El problema descrito anteriormente nunca se produce en el caso de la composición y, por tanto, hace que esta última sea preferible a la herencia.

2. El siguiente problema con la herencia es que exponemos todos los métodos del padre al cliente. Y si la superclase no está diseñada muy correctamente y contiene agujeros de seguridad. Entonces, aunque cuidemos por completo la seguridad en la implementación de nuestra subclase, seguiremos dependiendo de la implementación defectuosa de la clase principal.

   La composición nos ayuda a proporcionar acceso controlado a los métodos de una superclase, mientras que la herencia no mantiene ningún control sobre sus métodos. Ésta es también una de las principales ventajas de la composición sobre la herencia.

3. Otro beneficio de la composición es que agrega flexibilidad al llamar a métodos. La implementación de la clase ClassCdescrita anteriormente no es óptima y utiliza enlace temprano al método llamado. Los cambios mínimos nos permitirán hacer que las llamadas a métodos sean flexibles y permitirán la vinculación tardía (vinculación en tiempo de ejecución).

   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();
       }
   }

   El programa anterior mostrará:

   doSomething implementation of A
   doSomething implementation of B

   Esta flexibilidad en la llamada a métodos no se ve en la herencia, lo que hace que la composición sea el mejor enfoque.

4. Las pruebas unitarias son más fáciles en el caso de composición porque sabemos que para todos los métodos que se usan en la superclase podemos eliminar las pruebas, mientras que en herencia dependemos en gran medida de la superclase y no sabemos cómo funcionan los métodos de la clase principal. se utilizará. Entonces, debido a la herencia, tendremos que probar todos los métodos de la superclase, lo cual es un trabajo innecesario.

   Idealmente, la herencia solo debería usarse cuando la relación " es-a " es verdadera para las clases padre e hijo; de lo contrario, se debería preferir la composición.