جاوا میں ایک سے زیادہ وراثت۔ ساخت اور وراثت کا موازنہ

"ہیرے کا مسئلہ"

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 " رشتہ درست ہو، بصورت دیگر مرکب کو ترجیح دی جانی چاہیے۔