OOP اصول

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

OOP اصول:

1. وراثت
2. تجری
3. انکیپسولیشن
4. پولیمورفزم

آبجیکٹ اورینٹڈ پروگرامنگ (OOP) کیا ہے

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

Begin
  Class Rectangle (Width, Height); Real Width, Height;

   Begin
      Real Area, Perimeter;

      Procedure Update;
      Begin
        Area := Width * Height;
              OutText("Rectangle is updating, Area = "); OutFix(Area,2,8); OutImage;
        Perimeter := 2*(Width + Height);
              OutText("Rectangle is updating, Perimeter = "); OutFix(Perimeter,2,8); OutImage;
      End of Update;

      Update;
      OutText("Rectangle created: "); OutFix(Width,2,6);
      OutFix(Height,2,6); OutImage;
   End of Rectangle;

       Rectangle Class ColouredRectangle (Color); Text Color;

  Begin
      OutText("ColouredRectangle created, color = "); OutText(Color);
      OutImage;
        End of ColouredRectangle;


         Ref(Rectangle) Cr;
   Cr :- New ColouredRectangle(10, 20, "Green");
End;

کوڈ کی مثال مضمون Simula - OOP کے 50 سال سے لی گئی ہے ۔ جیسا کہ آپ دیکھ سکتے ہیں، جاوا اور اس کے آباؤ اجداد ایک دوسرے سے اتنے مختلف نہیں ہیں :) یہ اس حقیقت کی وجہ سے ہے کہ سمولا کی ظاہری شکل نے ایک نئے تصور - آبجیکٹ پر مبنی پروگرامنگ کی پیدائش کو نشان زد کیا۔ ویکیپیڈیا OOP کی مندرجہ ذیل تعریف دیتا ہے: آبجیکٹ اورینٹڈ پروگرامنگ (OOP) ایک پروگرامنگ طریقہ کار ہے جس کی بنیاد پر ایک پروگرام کو اشیاء کے مجموعہ کے طور پر پیش کیا جاتا ہے، جن میں سے ہر ایک مخصوص طبقے کی مثال ہے، اور کلاسیں ایک وراثتی درجہ بندی تشکیل دیتی ہیں۔ میرے خیال میں یہ بہت کامیاب ہے۔ آپ نے حال ہی میں جاوا سیکھنا شروع کیا ہے، لیکن اس میں شاید ہی کوئی ایسے الفاظ ہوں جو آپ کے لیے ناواقف ہوں :) آج OOP پروگرامنگ کا سب سے عام طریقہ کار ہے۔ جاوا کے علاوہ، OOP اصول بہت سی مشہور زبانوں میں استعمال ہوتے ہیں جن کے بارے میں آپ نے سنا ہوگا۔ یہ ہیں C++ (یہ کمپیوٹر گیم ڈویلپرز کے ذریعے فعال طور پر استعمال ہوتا ہے)، آبجیکٹو-سی اور سوئفٹ (وہ ایپل ڈیوائسز کے لیے پروگرام لکھتے ہیں)، ازگر (مشین لرننگ میں سب سے زیادہ مانگ)، پی ایچ پی (ویب ڈویلپمنٹ کی مقبول ترین زبانوں میں سے ایک)، JavaScript (سادہ کہتے ہیں جو وہ اس پر نہیں کرتے) اور بہت سے دوسرے۔ دراصل، OOP کے یہ "اصول" کیا ہیں؟ آئیے آپ کو مزید تفصیل سے بتاتے ہیں۔

OOP اصول

یہ بنیادی باتیں ہیں۔ 4 اہم خصوصیات جو مل کر آبجیکٹ اورینٹڈ پروگرامنگ پیراڈائم بناتے ہیں۔ ان کو سمجھنا ایک کامیاب پروگرامر بننے کی کلید ہے۔

اصول 1. وراثت

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

اصول 2. خلاصہ

یہ بہت سادہ اصول ہے۔ تجرید کا مطلب ہے کسی چیز کی اہم، اہم ترین خصوصیات کو اجاگر کرنا اور اس کے برعکس - ثانوی، غیر اہم خصوصیات کو ترک کرنا۔ آئیے پہیے کو دوبارہ ایجاد نہ کریں اور کلاسوں کے بارے میں ایک پرانے لیکچر کی ایک مثال یاد رکھیں۔ ہم کہتے ہیں کہ ہم کمپنی کے ملازمین کی فائل کیبنٹ بنا رہے ہیں۔ ملازم کی اشیاء بنانے کے لیے، ہم نے ایک کلاس لکھا Employee۔ کمپنی کی فائل میں ان کی تفصیل کے لیے کون سی خصوصیات اہم ہیں؟ پورا نام، تاریخ پیدائش، سوشل سیکورٹی نمبر، ٹیکس شناختی نمبر۔ لیکن اس بات کا امکان نہیں ہے کہ ہمیں اس قسم کے کارڈ میں اس کے قد، آنکھ اور بالوں کے رنگ کی ضرورت ہو۔ کمپنی کو ملازم کے بارے میں اس معلومات کی ضرورت نہیں ہے۔ لہذا، کلاس کے لیے Employeeہم متغیرات String name،، اور، کو سیٹ کریں گے اور ہم ان معلومات کو ترک کر دیں گے جو ہمارے لیے غیر ضروری ہے، جیسے کہ آنکھوں کا رنگ، اور اس کا خلاصہ int age۔ لیکن اگر ہم کسی ایجنسی کے لیے فوٹو ماڈلز کا کیٹلاگ بناتے ہیں تو صورتحال ڈرامائی طور پر بدل جاتی ہے۔ فیشن ماڈل کو بیان کرنے کے لیے، قد، آنکھوں کا رنگ اور بالوں کا رنگ ہمارے لیے بہت اہم ہے، لیکن TIN نمبر کی ضرورت نہیں ہے۔ لہذا، کلاس میں ہم متغیر بناتے ہیں ، .int socialInsuranceNumberint taxNumberModelString heightString hairString eyes

اصول 3: انکیپسولیشن

ہم پہلے ہی اس کا سامنا کر چکے ہیں۔ جاوا میں Encapsulation کا مطلب ہے ڈیٹا تک رسائی اور اسے تبدیل کرنے کی صلاحیت کو محدود کرنا۔ جیسا کہ آپ دیکھ سکتے ہیں، یہ لفظ "کیپسول" پر مبنی ہے۔ اس "کیپسول" میں ہم اپنے لیے کچھ اہم ڈیٹا چھپاتے ہیں جسے ہم نہیں چاہتے کہ کوئی بدلے۔ زندگی سے ایک سادہ سی مثال۔ آپ کا پہلا اور آخری نام ہے۔ ہر کوئی آپ کو جانتا ہے انہیں جانتا ہے. لیکن ان کے پاس آپ کا پہلا اور آخری نام تبدیل کرنے کی رسائی نہیں ہے۔ یہ عمل، کوئی کہہ سکتا ہے، پاسپورٹ آفس میں "انکیپسلیٹڈ" ہے: آپ وہاں صرف اپنا پہلا اور آخری نام تبدیل کر سکتے ہیں، اور صرف آپ ہی کر سکتے ہیں۔ دوسرے "صارفین" کے پاس آپ کے پہلے اور آخری نام تک صرف پڑھنے کی رسائی ہے :) ایک اور مثال آپ کے اپارٹمنٹ میں موجود رقم ہے۔ انہیں کمرے کے وسط میں سادہ نظروں میں چھوڑنا اچھا خیال نہیں ہے۔ کوئی بھی "صارف" (ایک شخص جو آپ کے گھر آتا ہے) آپ کے پیسے کا نمبر تبدیل کر سکے گا، یعنی انہیں اٹھا. یہ بہتر ہے کہ انہیں محفوظ جگہ میں سمیٹ لیں۔ صرف آپ کو رسائی حاصل ہوگی اور صرف ایک خاص کوڈ کے ساتھ۔ انکیپسولیشن کی واضح مثالیں جن کے ساتھ آپ پہلے ہی کام کر چکے ہیں رسائی موڈیفائر ( private، publicوغیرہ) اور گیٹر سیٹٹرز ہیں۔ اگر ageکلاس فیلڈ Catانکیپسولیٹ نہیں ہے، تو کوئی بھی لکھ سکتا ہے:

Cat.age = -1000;

اور encapsulation میکانزم ہمیں ageسیٹر کے طریقہ کار کے ساتھ فیلڈ کی حفاظت کرنے کی اجازت دیتا ہے، جس میں ہم یہ چیک کر سکتے ہیں کہ عمر منفی نمبر نہیں ہو سکتی۔

اصول 4. پولیمورفزم

پولیمورفزم ایک سے زیادہ اقسام کا علاج کرنے کی صلاحیت ہے جیسے کہ وہ ایک ہی قسم کے ہوں۔ اس صورت میں، اشیاء کا طرز عمل اس قسم کے لحاظ سے مختلف ہوگا جس سے وہ تعلق رکھتے ہیں۔ تھوڑا سا پیچیدہ لگتا ہے؟ آئیے اب اس کا پتہ لگائیں۔ آئیے سب سے آسان مثال لیتے ہیں - جانور۔ آئیے Animalایک ہی طریقہ کے ساتھ ایک کلاس بنائیں - voice(), اور اس کی دو اولادیں - Catاور Dog۔

public class Animal {

   public void voice() {

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

public class Dog extends Animal {


   @Override
   public void voice() {
       System.out.println("Bow-wow!");
   }
}

public class Cat extends Animal {

   @Override
   public void voice() {
       System.out.println("Meow!");
   }
}

اب ایک لنک بنانے کی کوشش کریں Animalاور اسے ایک آبجیکٹ تفویض کریں Dog۔

public class Main {

   public static void main(String[] args) {

       Animal dog = new Dog();
       dog.voice();
   }
}

آپ کے خیال میں کون سا طریقہ کہا جائے گا؟ Animal.voice()یا Dog.voice()_ کلاس کا طریقہ کہا جائے گا Dog: Woof-woof! ہم نے ایک حوالہ بنایا Animal، لیکن آبجیکٹ اس طرح برتاؤ کرتا ہے Dog۔ اگر ضروری ہو تو وہ بلی، گھوڑے یا دوسرے جانور کی طرح برتاؤ کر سکتا ہے۔ اہم بات یہ ہے کہ Animalکسی مخصوص نسلی طبقے کی کسی چیز کو عام قسم کا حوالہ تفویض کیا جائے۔ یہ منطقی ہے، کیونکہ تمام کتے جانور ہیں۔ ہمارا یہی مطلب تھا جب ہم نے کہا کہ "آجیکٹس مختلف طریقے سے برتاؤ کریں گی اس پر منحصر ہے کہ وہ کس قسم کی ہیں۔" اگر ہم ایک آبجیکٹ بنائیں Cat-

public static void main(String[] args) {

   Animal cat = new Cat();
   cat.voice();
}

طریقہ voice()"میاؤ!" "کئی اقسام کے ساتھ کام کرنے کی صلاحیت کا کیا مطلب ہے جیسے کہ وہ ایک ہی قسم کے ہوں"؟ یہ بھی کافی آسان ہے۔ آئیے تصور کریں کہ ہم جانوروں کے لیے ہیئر ڈریسنگ سیلون بنا رہے ہیں۔ shear()ہمارے ہیئر سیلون کو تمام جانوروں کو کاٹنے کے قابل ہونا چاہیے، لہذا ہم پیرامیٹر کے ساتھ ایک طریقہ ("کٹ") بنائیں گے Animal- وہ جانور جسے ہم کاٹیں گے۔

public class AnimalBarbershop {

   public void shear(Animal animal) {

       System.out.println("The haircut is ready!");
   }
}

اور اب ہم shearاشیاء Catاور اشیاء دونوں کو طریقہ میں منتقل کر سکتے ہیں Dog!

public static void main(String[] args) {

   Cat cat = new Cat();
   Dog dog = new Dog();

   AnimalBarbershop barbershop = new AnimalBarbershop();

   barbershop.shear(cat);
   barbershop.shear(dog);
}

یہاں ایک واضح مثال ہے: کلاس AnimalBarbershopاس طرح کام کرتی ہے Catجیسے Dogوہ ایک ہی قسم کی ہوں۔ ایک ہی وقت میں، ان کا رویہ Catمختلف ہے Dog: وہ اپنی آواز کو مختلف طریقے سے استعمال کرتے ہیں۔

OOP کے ظاہر ہونے کی وجوہات

پروگرامنگ کا یہ نیا تصور - OOP - یہاں تک کہ کیوں پیدا ہوا ؟ پروگرامرز کے پاس ایسے اوزار تھے جو کام کرتے تھے: طریقہ کار کی زبانیں، مثال کے طور پر۔ کس چیز نے انہیں بنیادی طور پر کوئی نئی چیز ایجاد کرنے پر اکسایا؟ سب سے پہلے، ان کاموں کی پیچیدگی جن کا سامنا کرنا پڑا۔ اگر 60 سال پہلے کسی پروگرامر کا کام ایسا لگتا تھا کہ "ریاضی کی مساوات کا حساب لگائیں فلاں فلاں"، اب یہ ایسا لگ سکتا ہے کہ "گیم STALKER کے لیے 7 مختلف انجام لاگو کریں اس پر منحصر ہے کہ صارف گیم لمحات A, B, C, D میں کیا فیصلے کرتا ہے۔ ، E، F اور ان حلوں کے امتزاج۔" کام، جیسا کہ آپ دیکھ سکتے ہیں، پچھلی دہائیوں میں واضح طور پر زیادہ پیچیدہ ہو گئے ہیں۔ اس کا مطلب ہے کہ ڈیٹا کی اقسام زیادہ پیچیدہ ہو گئی ہیں۔ یہ OOP کے ابھرنے کی ایک اور وجہ ہے۔ مساوات کے ساتھ مثال کو عام پرائمیٹوز کا استعمال کرتے ہوئے آسانی سے حل کیا جا سکتا ہے؛ یہاں کسی چیز کی ضرورت نہیں ہے۔ لیکن آپ کی ایجاد کردہ کچھ کلاسوں کا استعمال کیے بغیر گیم کے اختتام کے مسئلے کو بیان کرنا بھی مشکل ہوگا۔ لیکن ایک ہی وقت میں، اسے کلاسز اور اشیاء میں بیان کرنا کافی آسان ہے: ہمیں ظاہر ہے گیم کلاس، اسٹالکر کلاس، اینڈنگ کلاس، پلیئرز ڈیسیژن کلاس، گیم مومنٹ کلاس، وغیرہ کی ضرورت ہوگی۔ یعنی، کسی مسئلے کو حل کرنا شروع کیے بغیر بھی، ہم آسانی سے اپنے ذہن میں اس کے حل کے "خاکے" کا تصور کر سکتے ہیں۔ مسائل کی بڑھتی ہوئی پیچیدگی نے پروگرامرز کو مسئلہ کو حصوں میں تقسیم کرنے پر مجبور کر دیا ہے۔ لیکن پروسیجرل پروگرامنگ میں یہ اتنا آسان نہیں تھا۔ اور اکثر یہ پروگرام شاخوں کے ایک گروپ کا "درخت" ہوتا تھا جس کے آپریشن کے لیے تمام ممکنہ اختیارات ہوتے تھے۔ کچھ شرائط پر منحصر ہے، پروگرام کو ایک یا دوسری شاخ کے ساتھ انجام دیا گیا تھا۔ چھوٹے پروگراموں کے لیے یہ آپشن آسان تھا، لیکن ایک بڑے کام کو حصوں میں تقسیم کرنا بہت مشکل تھا۔ یہ ضرورت OOP کے ابھرنے کی ایک اور وجہ بن گئی۔ اس تصور نے پروگرامرز کو ایک پروگرام کو کلاسز کے "ماڈیولز" کے ایک گروپ میں تقسیم کرنے کی صلاحیت فراہم کی، جن میں سے ہر ایک نے اپنے کام کا اپنا حصہ کیا۔ تمام اشیاء، ایک دوسرے کے ساتھ بات چیت کرتے ہوئے، ہمارے پروگرام کا کام بناتے ہیں۔ اس کے علاوہ، ہم جو کوڈ لکھتے ہیں اسے پروگرام میں کسی اور جگہ دوبارہ استعمال کیا جا سکتا ہے، جس سے کافی وقت بھی بچ جاتا ہے۔