جاوا میں خلاصہ کلاسیں ٹھوس مثالوں کے ساتھ

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

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

آپ کو شاید یاد ہوگا کہ "تجزیہ" کیا ہے - ہم پہلے ہی اس کا احاطہ کر چکے ہیں :) اگر آپ اچانک بھول گئے ہیں، تو ٹھیک ہے، آئیے یاد رکھیں: یہ 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;
   }
}

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

public class Sedan extends Car {

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

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

}

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

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 OK, the machine has been created
   }
}

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

public abstract class Car {

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

   public void gas() {
       System.out.println("Let's go!");
   }

   public abstract void brake();

   //getters and setters
}


public class Sedan extends Car {

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

}

public class Main {

   public static void main(String[] args) {

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

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

جاوا میں متعدد طبقاتی وراثت کیوں نہیں ہے؟

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

public class Toster {


 public void on() {

       System.out.println("The toaster is on, the toast is getting ready!");
   }

   public void off() {

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


public class NuclearBomb {

   public void on() {

       System.out.println("Взрыв!");
   }
}

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

public class MysteriousDevice extends Toster, NuclearBomb {

   public static void main(String[] args) {

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

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

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

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