การสืบทอดหลายรายการใน 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();
    }
}

Композиция How спасение

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

Композиция or наследование?

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

   Код выше прекрасно компorруется и работает, но что, если ClassC будет реализован иначе:

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

   Отметьте, что метод test() уже существует в классе наследнике, но возвращает результат другого типа. Теперь ClassD, в случае если вы используете IDE, не будет скомпorрован. Вам будет рекомендовано изменить тип возвращаемого результата в классе наследнике or в суперклассе.

   Теперь представим себе такую ситуацию, где имеется многоуровневое наследование классов и суперкласс не доступен для наших изменений. Теперь, чтобы избавиться от ошибки компиляции, у нас нет других вариантов, кроме How изменить сигнатуру or Name метода подкласса. Также нам придется внести изменения во все места, где этот метод вызывался. Таким образом, наследование делает наш code хрупким.

   Проблема, описанная выше, никогда не встречается в случае композиции, и поэтому делает последнюю более предпочтительной перед наследованием.

2. Следующая проблема с наследованием заключается в том, что мы демонстрируем все методы родителя клиенту. И если суперкласс разработан не очень корректно и содержит дыры в «безопасности». Тогда, несмотря на то, что мы fully позаботимся о безопасности при реализации нашего подкласса, мы все равно будем зависеть от ущербной реализации класса-родителя.

   Композиция помогает нам в обеспечении контролируемого доступа к методам суперкласса, тогда How наследование не поддерживает ниHowого контроля над его методами. Это - также одно из главных преимуществ композиции над наследованием.

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. การทดสอบหน่วยนั้นง่ายกว่าในกรณีของการจัดองค์ประกอบเพราะเรารู้ว่าสำหรับวิธีการทั้งหมดที่ใช้ในซูเปอร์คลาสนั้น เราสามารถ stub การทดสอบได้ ในขณะที่ในการสืบทอดนั้น เราต้องพึ่งพาซูเปอร์คลาสเป็นอย่างมาก และไม่รู้ว่าวิธีการของคลาสพาเรนต์เป็นอย่างไร จะถูกนำไปใช้. ดังนั้นเนื่องจากการสืบทอด เราจะต้องทดสอบวิธีการทั้งหมดของซูเปอร์คลาส ซึ่งเป็นงานที่ไม่จำเป็น

   ตามหลักการแล้ว ควรใช้การสืบทอดเฉพาะเมื่อความสัมพันธ์ " is-a " เป็นจริงสำหรับคลาสพาเรนต์และคลาสรอง ไม่เช่นนั้นควรใช้องค์ประกอบมากกว่า