Множинне успадкування в Java. Порівняння композиції та наслідування

«Проблема Алмазу»

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

Множинне успадкування та інтерфейси

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

Композиція як порятунок

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

Композиція чи успадкування?

1. Припустимо, ми маємо наступну зв'язку класів батько-спадкоємець:

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

   Код вище чудово компілюється та працює, але що, якщо ClassCбуде реалізовано інакше:

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

   Зауважте, що метод test()вже існує у класі спадкоємця, але повертає результат іншого типу. Тепер ClassD, якщо ви використовуєте IDE, не буде скомпільовано. Вам буде рекомендовано змінити тип результату, що повертається в класі спадкоємця або в суперкласі.

   Тепер уявімо таку ситуацію, де є багаторівневе успадкування класів і суперклас не доступний для наших змін. Тепер, щоб позбутися помилки компіляції, ми не маємо інших варіантів, крім як змінити сигнатуру або ім'я методу підкласу. Також нам доведеться внести зміни до всіх місць, де цей метод викликався. Таким чином, успадкування робить наш код крихким.

   Проблема, описана вище, ніколи не зустрічається у разі композиції, і тому робить останню кращою перед успадкуванням.

2. Наступна проблема з наслідуванням полягає в тому, що ми демонструємо всі методи батька клієнту. І якщо суперклас розроблений не дуже коректно і містить дірки у «безпеці». Тоді, незважаючи на те, що ми повністю подбаємо про безпеку при реалізації нашого підкласу, ми все одно залежатимемо від неповної реалізації класу-батька.

   Композиція допомагає нам у забезпеченні контрольованого доступу до методів суперкласу, тоді як спадкування не підтримує жодного контролю за його методами. Це також одна з головних переваг композиції над спадкуванням.

3. Ще одна перевага композиції – те, що вона додає гнучкості при виклику методів. Реалізація класу ClassC, описана вище, не оптимальна і використовує раннє зв'язування з методом, що викликається. Мінімальні зміни дозволять нам зробити виклик методів гнучким та забезпечити пізнє зв'язування (зв'язування під час виконання).

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

   Програма виведе на екран:

   doSomething implementation of A
   doSomething implementation of B

   Ця гнучкість при виклику методу не спостерігається при успадкування, що змушує використовувати композицію як найкращий підхід.

4. Модульне тестування простіше у разі композиції, тому що ми знаємо, що для всіх методів, які використовуються в суперкласі, ми можемо поставити заглушку для тестів, у той час як у спадкуванні ми сильно залежимо від суперкласу і не знаємо, як методи класу-батька будуть використані. Таким чином, через спадкування нам доведеться тестувати всі методи суперкласу, що є зайвою роботою.

   В ідеалі, успадкування слід використовувати лише тоді, коли відношення ” is-a ” справедливе для класів батька та спадкоємця, інакше варто віддати перевагу композиції.