الوراثة المتعددة في جافا مقارنة التكوين والميراث

"مشكلة الماس"

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 " صحيحة بالنسبة لفئات الوالدين والأبناء، وإلا فيجب تفضيل التركيب.