جاوا میں تجریدی کلاسوں کی مخصوص مثالیں۔

ہائے! پچھلے اسباق میں، ہم نے انٹرفیس سے ملاقات کی اور اندازہ لگایا کہ وہ کس کے لیے ہیں۔ آج کا موضوع پچھلے موضوع کی بازگشت کرے گا۔ آئیے جاوا میں خلاصہ کلاسوں کے بارے میں بات کرتے ہیں۔

کلاسوں کو 'خلاصہ' کیوں کہا جاتا ہے

آپ کو شاید یاد ہوگا کہ 'خلاصہ' کیا ہے - ہم اس پر پہلے ہی گزر چکے ہیں۔ :) بھول گئے تو ڈرو نہیں۔ یاد رکھیں: یہ OOP کا ایک اصول ہے جو کہتا ہے کہ کلاسز کو ڈیزائن کرتے وقت اور اشیاء تخلیق کرتے وقت، ہمیں صرف ہستی کی اہم خصوصیات کی نشاندہی کرنی چاہیے اور معمولی کو ضائع کرنا چاہیے۔ مثال کے طور پر، اگر ہم SchoolTeacherکلاس ڈیزائن کر رہے ہیں، تو ہمیں شاید ہی ' اونچائی ' پراپرٹی کی ضرورت ہو۔ درحقیقت، یہ جائیداد استاد کے لیے غیر متعلقہ ہے۔ لیکن اگر ہم ایک BasketballPlayerکلاس بنا رہے ہیں، تو ترقی ایک اہم خصوصیت ہوگی۔ تو سنو۔ ایک خلاصہ کلاس اتنا ہی خلاصہ ہوتا ہے جتنا وہ آتا ہے - مستقبل کی کلاسوں کے گروپ کے لیے ایک نامکمل 'خالی'۔ خالی کو جیسا ہے استعمال نہیں کیا جا سکتا۔ یہ بہت 'کچا' ہے۔ لیکن یہ کچھ مخصوص حالت اور عمومی رویے کی وضاحت کرتا ہے جو مستقبل کی کلاسوں کے پاس ہوں گے جو تجریدی طبقے کے وارث ہوں گے۔

خلاصہ جاوا کلاسز کی مثالیں۔

کاروں کے ساتھ ایک سادہ مثال پر غور کریں:

public abstract class Car {

   private String model;
   private String color;
   private int maxSpeed;

   public abstract void gas();

   public abstract void brake();

   public String getModel() {
       return model;
   }

   public void setModel(String model) {
       this.model = model;
   }

   public String getColor() {
       return color;
   }

   public void setColor(String color) {
       this.color = color;
   }

   public int getMaxSpeed() {
       return maxSpeed;
   }

   public void setMaxSpeed(int maxSpeed) {
       this.maxSpeed = maxSpeed;
   }
}

یہ وہی ہے جو سب سے آسان خلاصہ کلاس کی طرح لگتا ہے۔ جیسا کہ آپ دیکھ سکتے ہیں، یہ کچھ خاص نہیں ہے :) ہمیں اس کی ضرورت کیوں پڑے گی؟ سب سے پہلے، یہ ہماری مطلوبہ ہستی، ایک کار، کو انتہائی تجریدی انداز میں بیان کرتا ہے۔ ایک وجہ ہے کہ ہم لفظ abstract استعمال کر رہے ہیں ۔ حقیقی دنیا میں، کوئی 'خلاصہ کاریں' نہیں ہیں۔ یہاں ٹرک، ریس کاریں، سیڈان، کوپس اور ایس یو وی ہیں۔ ہماری تجریدی کلاس صرف ایک 'بلیو پرنٹ' ہے جسے ہم بعد میں کار کلاسز بنانے کے لیے استعمال کریں گے۔

public class Sedan extends Car {

   @Override
   public void gas() {
       System.out.println("The sedan is accelerating!");
   }

   @Override
   public void brake() {
       System.out.println("The sedan is slowing down!");
   }

}

یہ بالکل اسی طرح ہے جس کے بارے میں ہم نے وراثت کے اسباق میں بات کی تھی۔ لیکن ان اسباق میں، ہمارے پاس کار کلاس تھی اور اس کے طریقے خلاصہ نہیں تھے۔ لیکن اس حل میں بہت سی خرابیاں ہیں جو خلاصہ کلاسوں میں طے کی گئی ہیں۔ سب سے پہلے اور اہم بات یہ ہے کہ آپ تجریدی کلاس کی مثال نہیں بنا سکتے :

public class Main {

   public static void main(String[] args) {

       Car car = new Car(); // Error! The Car class is abstract!
   }
}

جاوا کے تخلیق کاروں نے خاص طور پر اس 'فیچر' کو ڈیزائن کیا ہے۔ ایک بار پھر، ایک یاد دہانی کے طور پر: ایک خلاصہ کلاس مستقبل کی 'نارمل' کلاسوں کے لیے صرف ایک خاکہ ہے ۔ آپ کو بلیو پرنٹ کی کاپیوں کی ضرورت نہیں ہے، ٹھیک ہے؟ اور آپ تجریدی کلاس کی مثالیں نہیں بناتے ہیں :) لیکن اگر Carکلاس خلاصہ نہ ہوتی تو ہم آسانی سے اس کی مثالیں بنا سکتے تھے۔

public class Car {

   private String model;
   private String color;
   private int maxSpeed;

   public void gas() {
       // Some logic
   }

    public void brake() {
       // Some logic
   }
}


public class Main {

   public static void main(String[] args) {

       Car car = new Car(); // Everything is fine. A car is created.
   }
}

اب ہمارے پروگرام میں کسی طرح کی ناقابل فہم کار ہے — یہ ٹرک نہیں، ریس کار نہیں، سیڈان نہیں، اور یہ بالکل واضح نہیں ہے کہ یہ کیا ہے۔ یہ بالکل 'خلاصہ کار' ہے جو فطرت میں موجود نہیں ہے۔ ہم جانوروں کا استعمال کرتے ہوئے ایک ہی مثال پیش کر سکتے ہیں۔ تصور کریں کہ اگر Animalکلاسز ( تجریدی جانور )۔ یہ واضح نہیں ہے کہ یہ کس قسم کا جانور ہے، اس کا تعلق کس خاندان سے ہے، اور اس کی کیا خصوصیات ہیں۔ آپ کے پروگرام میں یہ دیکھنا عجیب ہوگا۔ فطرت میں کوئی 'خلاصہ جانور' نہیں ہیں۔ صرف کتے، بلی، لومڑی، تل وغیرہ۔ تجریدی کلاسیں ہمیں تجریدی اشیاء سے بچاتی ہیں۔ وہ ہمیں بنیادی حالت اور طرز عمل دیتے ہیں۔ مثال کے طور پر، تمام کاروں کا ماڈل ، رنگ ، اور زیادہ سے زیادہ رفتار ہونی چاہیے ، اور آپ کو گیس اور بریک لگانے کے قابل ہونا چاہیے ۔ یہی ہے. یہ ایک عمومی تجریدی منصوبہ ہے۔ اس کے بعد آپ اپنی مطلوبہ کلاسز کو ڈیزائن کریں۔ نوٹ: خلاصہ کلاس میں دو طریقوں کو بھی abstract کے طور پر نامزد کیا گیا ہے ، اور ان کا کوئی نفاذ نہیں ہے۔ وجہ ایک ہی ہے: خلاصہ کلاسیں تجریدی کاروں کے لئے پہلے سے طے شدہ سلوک نہیں کرتی ہیں۔ وہ صرف اس بات کی نشاندہی کرتے ہیں کہ ہر کار کو کیا کرنے کے قابل ہونا چاہئے۔ تاہم، اگر آپ کو پہلے سے طے شدہ رویے کی ضرورت ہے، تو آپ تجریدی کلاس میں طریقوں کو نافذ کر سکتے ہیں۔ جاوا اس کی ممانعت نہیں کرتا ہے:

public abstract class Car {

   private String model;
   private String color;
   private int maxSpeed;

   public void gas() {
       System.out.println("Gas!");
   }

   public abstract void brake();

   // Getters and setters
}


public class Sedan extends Car {

   @Override
   public void brake() {
       System.out.println("The sedan is slowing down!");
   }

}

public class Main {

   public static void main(String[] args) {

       Sedan sedan = new Sedan();
       sedan.gas();
   }
}

کنسول آؤٹ پٹ: "گیس!" جیسا کہ آپ دیکھ سکتے ہیں، ہم نے تجریدی کلاس میں پہلا طریقہ نافذ کیا ہے، نہ کہ دوسرا۔ نتیجے کے طور پر، ہماری Sedanکلاس کا رویہ دو حصوں میں تقسیم ہو گیا ہے: اگر آپ gas()طریقہ کو کال کرتے ہیں، تو کال خلاصہ پیرنٹ کلاس تک 'اٹھتا ہے' Car، لیکن ہم نے کلاس brake()میں طریقہ کو اوورروڈ کر دیا Sedanہے۔ یہ بہت آسان اور لچکدار نکلا ہے۔ لیکن اب ہماری کلاس اتنی خلاصہ نہیں ہے ؟ آخر کار، اس کے آدھے طریقے لاگو ہو چکے ہیں۔ دراصل ایک بہت اہم خصوصیت ہے - ایک کلاس خلاصہ ہے اگر اس کے طریقوں میں سے کم از کم ایک خلاصہ ہو ۔ دو طریقوں میں سے ایک، یا کم از کم ہزار طریقوں میں سے ایک - اس سے کوئی فرق نہیں پڑتا ہے۔ ہم تمام طریقوں کو لاگو بھی کر سکتے ہیں اور کوئی بھی نہیں چھوڑ سکتے۔ پھر یہ تجریدی طریقوں کے بغیر ایک تجریدی کلاس ہوگی۔ اصولی طور پر، یہ ممکن ہے، اور مرتب کرنے والا غلطیاں پیدا نہیں کرے گا، لیکن اس سے بچنا بہتر ہے: لفظ خلاصہ اپنا معنی کھو دیتا ہے، اور آپ کے ساتھی پروگرامرز بہت حیران ہوں :/ ساتھ ہی، اگر کسی طریقہ پر لفظ خلاصہ کا نشان لگایا گیا ہو، تو ہر بچے کی کلاس کو اسے لاگو کرنا چاہیے یا اسے خلاصہ قرار دینا چاہیے۔ بصورت دیگر، مرتب کرنے والا ایک خرابی پیدا کرے گا۔ بلاشبہ، ہر طبقہ صرف ایک تجریدی طبقے کو وراثت میں لے سکتا ہے، لہذا وراثت کے لحاظ سے تجریدی اور عام کلاسوں میں کوئی فرق نہیں ہے۔ اس سے کوئی فرق نہیں پڑتا کہ ہم ایک تجریدی کلاس کے وارث ہیں یا ایک عام، صرف ایک پیرنٹ کلاس ہو سکتی ہے۔

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

ہم پہلے ہی کہہ چکے ہیں کہ جاوا میں ایک سے زیادہ وراثت نہیں ہے، لیکن ہم نے واقعی اس کی وجہ دریافت نہیں کی ہے۔ آئیے اب ایسا کرنے کی کوشش کرتے ہیں۔ حقیقت یہ ہے کہ اگر جاوا کے پاس ایک سے زیادہ وراثت ہے تو، بچوں کی کلاسیں یہ فیصلہ نہیں کر پائیں گی کہ انہیں کون سا مخصوص طرز عمل منتخب کرنا چاہیے۔ فرض کریں کہ ہمارے پاس دو کلاسز ہیں - Toasterاور NuclearBomb:

public class Toaster {


 public void on() {

       System.out.println("The toaster is on. Toast is being prepared!");
   }

   public void off() {

       System.out.println("The toaster is off!");
   }
}


public class NuclearBomb {

   public void on() {

       System.out.println("Boom!");
   }
}

جیسا کہ آپ دیکھ سکتے ہیں، دونوں کا ایک on()طریقہ ہے۔ ٹوسٹر کے لیے، یہ ٹوسٹ کرنا شروع کر دیتا ہے۔ جوہری بم کے لیے، یہ ایک دھماکہ کرتا ہے۔ افوہ: / اب تصور کریں کہ آپ نے درمیان میں کچھ تخلیق کرنے کا فیصلہ کیا (مجھ سے کیوں نہ پوچھیں!)۔ اور اس طرح آپ کی ایک MysteriousDeviceکلاس ہے! یہ کوڈ، یقیناً، کام نہیں کرتا، اور ہم اسے صرف ایک مثال کے طور پر فراہم کرتے ہیں 'لیکن یہ ہو سکتا ہے':

public class MysteriousDevice extends Toaster, NuclearBomb {

   public static void main(String[] args) {

       MysteriousDevice mysteriousDevice = new MysteriousDevice();
       mysteriousDevice.on(); // So what should happen here? Do we get toast or a nuclear apocalypse?
   }
}

آئیے ایک نظر ڈالتے ہیں کہ ہمارے پاس کیا ہے۔ پراسرار ڈیوائس بیک وقت ٹوسٹر اور نیوکلیئر بم کا وارث ہے۔ دونوں کے پاس on()طریقے ہیں۔ نتیجے کے طور پر، اگر ہم on()طریقہ کو کہتے ہیں، تو یہ واضح نہیں ہے کہ MysteriousDeviceاعتراض پر کس کو پکارا جائے۔ ایسا کوئی طریقہ نہیں ہے کہ آبجیکٹ کو کبھی پتہ چل سکے۔ اور اس سب کو ختم کرنے کے لیے: نیوکلیئر بم کے پاس کوئی طریقہ نہیں ہے off()، لہذا اگر ہم نے صحیح اندازہ نہیں لگایا، تو ڈیوائس کو غیر فعال کرنا ناممکن ہو جائے گا۔ یہ خاص طور پر اس 'الجھن' کی وجہ سے ہے، جہاں آبجیکٹ کو یہ نہیں معلوم کہ کس طرز عمل کو ظاہر کرنا ہے، کہ جاوا کے تخلیق کاروں نے متعدد وراثت کو ترک کر دیا۔ تاہم، آپ کو یاد ہوگا کہ جاوا کلاسز متعدد انٹرفیس کو نافذ کر سکتی ہیں۔ ویسے، آپ کی پڑھائی میں، آپ کو پہلے ہی کم از کم ایک تجریدی کلاس کا سامنا کرنا پڑا ہے! حالانکہ شاید آپ نے نوٹس بھی نہیں کیا :)

public abstract class Calendar implements Serializable, Cloneable, Comparable<Calendar>

یہ تمہارا پرانا دوست ہے، Calendarکلاس۔ یہ خلاصہ ہے اور اس کے کئی بچے ہیں۔ ان میں سے ایک ہے GregorianCalendar۔ آپ اسے تاریخوں کے اسباق میں پہلے ہی استعمال کر چکے ہیں۔ :) سب کچھ کافی واضح لگتا ہے۔ صرف ایک سوال ہے: ویسے بھی تجریدی کلاسز اور انٹرفیس میں بنیادی فرق کیا ہے؟ انہوں نے زبان کو صرف ایک تک محدود کرنے کے بجائے دونوں کو جاوا میں کیوں شامل کیا؟ سب کے بعد، یہ مکمل طور پر کافی ہوتا. ہم اگلے سبق میں اس کے بارے میں بات کریں گے ! تب تک :)