جاوا ڈویلپر کے انٹرویوز سے سوالات اور جوابات کا تجزیہ۔ حصہ 3

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

20. زبان کے کون سے عناصر encapsulation کے لیے ذمہ دار ہیں؟

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

21. زبان کے کون سے عناصر وراثت کے لیے ذمہ دار ہیں؟

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

public class Lion extends Cat

اور اس کا مطلب یہ ہے کہ شیر طبقے کو Cat کلاس کے تمام طریقے اور متغیرات وراثت میں ملتی ہیں ، سوائے جامد کے۔ نیز، وراثت کے ذمہ دار زبان کے عناصر میں شامل ہیں super ۔ یہ اس سے ملتا جلتا ایک حوالہ ہے ، لیکن جب کہ اس سے مراد وہ چیز ہے جس پر اسے بلایا گیا تھا، super سے مراد موجودہ پیرنٹ آبجیکٹ ہے۔ عام طور پر سپر استعمال کیا جاتا ہے:

1. سپر کلاس کنسٹرکٹر کو کال کرنے کے لیے: مثال کے طور پر، کیٹ کلاس کا ایک اندرونی متغیر نام ہے جسے کنسٹرکٹر میں شروع کرنے کی ضرورت ہے۔ شیر کلاس کنسٹرکٹر میں یہ اس طرح نظر آئے گا:

   public Lion(final String name) {
      super(name);
   }

2. پیرنٹ فیلڈز اور طریقوں تک رسائی کے لیے: مثال کے طور پر، کیٹ کلاس میں ہمارے پاس ابتدائی عمر کا فیلڈ ہے :

   public class Cat {
      int age = 10;

ایک ہی وقت میں، ہمارے پاس شعر میں وہی ابتدائی فیلڈ ہے :

public class Lion extends Cat {
   int age = 15;

اور اگر ہم شیر آبجیکٹ سے پیرنٹ آبجیکٹ کے عمر کے متغیر تک رسائی حاصل کرنا چاہتے ہیں تو ہمیں سپر کے ذریعے ایسا کرنے کی ضرورت ہے ۔

super.name

22. زبان کے کون سے عناصر پولیمورفزم کے لیے ذمہ دار ہیں؟

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

public class Cat implements Animal

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

23. ٹھوس کیا ہے؟ مثالیں دیں۔

SOLID OOP کے پانچ بنیادی ڈیزائن اصولوں کا مخفف ہے، جسے رابرٹ مارٹن نے تیار کیا ہے۔ S - واحد ذمہ داری کا اصول - واحد ذمہ داری کا اصول، جو کہتا ہے کہ ایک طبقے کا صرف ایک مقصد اور ایک ہی مقصد ہونا چاہیے۔ یعنی، آپ کو ایسی کلاسیں نہیں بنانا چاہئے جو سب کچھ کریں۔ اس صورت میں، آپ "ڈیوائن آبجیکٹ" اینٹی پیٹرن کو دوبارہ پیش کر سکتے ہیں۔ اگر آپ کے پاس Cat آبجیکٹ ہے، تو اس میں ایسے طریقے شامل ہونے چاہئیں جو صرف اس کی اندرونی فعالیت کے ساتھ تعامل کرتے ہیں، نہ کہ کاروباری منطق جو اس مثال سے متعلق نہیں ہے۔ مثال کے طور پر، اس قسم کی اشیاء کو کسی جگہ محفوظ کرنا۔ اس خارجی فعالیت ( کیٹ کے نسبت ) کو دوسری کلاسوں میں منتقل کرنے کی ضرورت ہے، کچھ خدمات جن کا کام اس قسم کی اشیاء کے لیے کاروباری منطق فراہم کرنا ہے۔ O - کھلے بند اصول - کھلے پن / بند ہونے کا اصول۔ اس کا مطلب یہ ہے کہ سافٹ ویئر اداروں (کلاسز، انٹرفیس) کو توسیع کے لیے کھلا ہونا چاہیے، لیکن ترمیم کے لیے بند ہونا چاہیے۔ مثال کے طور پر، ہمیں پہلے سے موجود Cat کلاس کی فعالیت جیسی فعالیت کی ضرورت تھی ، لیکن قدرے مختلف۔ کیٹ کلاس کی فعالیت کو تبدیل کرنے کے بجائے ، ان جگہوں کو توڑنے کے جہاں یہ پہلے سے استعمال ہوا ہے، ہم وراثت یا ساخت کا استعمال کرتے ہیں ۔ نتیجے کے طور پر، ہم نے Cat کلاس کی ترمیم شدہ فعالیت کے ساتھ اپنا مقصد حاصل کیا ، لیکن ساتھ ہی ہم نے اسے تبدیل نہیں کیا اور نہ ہی کچھ توڑا۔ L - Liskov متبادل اصول - Barbara Liskov کے متبادل اصول۔ اصول یہ بتاتا ہے کہ ایک فنکشن جو بیس قسم کا استعمال کرتا ہے اسے جانے بغیر بیس قسم کے ذیلی قسموں کو استعمال کرنے کے قابل ہونا چاہئے۔ مثال کے طور پر، ہماری بلی کی کلاس کو بنیادی طور پر رویے کو تبدیل کیے بغیر ، شیر کا کہنا ہے کہ اس کی اولاد میں سے کسی کے ساتھ تبادلہ ہونا چاہیے ۔ عمومی منطق (رویہ) وہی رہتا ہے، لیکن اس یا اس فعالیت کے نفاذ کی تفصیلات بدل جاتی ہیں۔ I - انٹرفیس علیحدگی کا اصول - انٹرفیس علیحدگی کا اصول۔ یہ اصول بتاتا ہے کہ ایک عالمگیر کے مقابلے میں بہت سے خصوصی (تختی مرکوز) انٹرفیس کا ہونا بہتر ہے۔ مثال کے طور پر، ایک صارف کچھ انٹرفیس لاگو کرتا ہے، جن میں سے اسے صرف اس طریقہ کی ضرورت ہوتی ہے، لیکن اس انٹرفیس میں مزید نو طریقے ہیں جن کا مطلوبہ طریقہ کی منطق سے کوئی تعلق نہیں ہے۔ اس صورت میں، صارف کو دس انٹرفیس طریقوں کو لاگو کرنے کی ضرورت ہوگی، جن میں سے نو اس کے لیے غیر ضروری ہیں! اس کے بجائے، دس مختلف انٹرفیس بنانا بہتر ہے جو ضرورت پڑنے پر لاگو کیا جا سکتا ہے۔ ٹھیک ہے، یا دس نہیں، بلکہ کئی، جن میں ایسے طریقے ہوں گے جن کا انٹرفیس کے مشترکہ مقصد سے گہرا تعلق ہے۔ D - انحصار الٹا اصول- انحصار الٹنے کا اصول۔ اصول یہ بتاتا ہے کہ اعلی سطح پر ماڈیولز کو نچلی سطح پر ماڈیولز پر انحصار نہیں کرنا چاہئے۔ اس اصول کو اس طرح بھی بیان کیا گیا ہے کہ " تجرید کا انحصار تفصیلات پر نہیں ہونا چاہیے، تفصیلات کا انحصار تجرید پر ہونا چاہیے۔" یعنی، ہمیں اپنی منطق کو انٹرفیس کا حوالہ دے کر تیار کرنا چاہیے، اور تب ہی مخصوص اشیاء کو اس فعالیت میں منتقل کرنا چاہیے، جن کی کلاسیں مطلوبہ انٹرفیس کو نافذ کرتی ہیں۔ مثال کے طور پر، اگر ہمارے پاس Cat کا انٹرفیس ہے اور اس کے کچھ نفاذ، کہتے ہیں، Lion اور HomeCat ، تو ہم اپنی تعامل کی منطق کو خاص طور پر Cat انٹرفیس کی قسم کے ساتھ بناتے ہیں، اور تب ہی Lion یا HomeCat کے مخصوص نفاذ کو تبدیل کرتے ہیں ، لیکن اس کے برعکس نہیں۔

24. کلاس، آبجیکٹ، انٹرفیس کیا ہے؟

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

25. POJO کلاس کیا ہے؟ ایسی کلاس کی مثال دیں۔

POJO - سادہ پرانا جاوا آبجیکٹ - ایک اچھا پرانا جاوا آبجیکٹ: کلاس کا ایک سادہ آبجیکٹ جو کسی مخصوص طبقے سے وراثت میں نہیں ملتا ہے اور کاروباری ماڈل کے لیے درکار کسی بھی سروس انٹرفیس کو لاگو نہیں کرتا ہے۔ دوسرے الفاظ میں ، POJO کلاس صرف ایک کلاس ہے جس کی کوئی خاص ضرورت نہیں ہے۔ ضرورت صرف ایک مخصوص فریم ورک سے منسلک مختلف گھنٹیوں اور سیٹیوں کی عدم موجودگی ہے۔ ایک اصول کے طور پر، ایسی کلاسیں دوسری کلاسوں سے وراثت میں نہیں ملتی ہیں (سوائے ایک ہی پیکیج سے POJO کلاسز کے)، انٹرفیس کو لاگو نہیں کرتے ہیں - بعض اوقات معیاری لائبریری سے مارکر انٹرفیس کے لیے ایک استثناء بنایا جاتا ہے جیسے سیریلائز ایبل یا کلون ایبل - تشریحات کا استعمال نہ کریں۔ اور تیسرے فریق کی لائبریریوں پر انحصار نہ کریں۔ لیکن میں نوٹ کرتا ہوں کہ POJOs میں کاروباری منطق اور کسی بھی قسم کے کنسٹرکٹرز کے ساتھ طریقے ہوسکتے ہیں۔ اگر آپ ان تشریحات کی اجازت دیتے ہیں جو کلاس کے سیمنٹکس میں تبدیلی نہیں کرتے ہیں (جس کے بغیر آبجیکٹ کا مقصد اور اس کے عمل کی منطق تبدیل نہیں ہوگی)، POJOs میں JPA Entity entities اور DTO آبجیکٹس کو بھی شامل کیا جا سکتا ہے جو XML یا JSON سے ڈی سیریلائز کیا گیا ہے ۔ قواعد جن کے لیے تشریحات میں وضاحت کی گئی ہے۔ POJO کلاسز کے لیے Equals اور hashCode کو اوور رائڈ کرنے کا بھی مشورہ دیا جاتا ہے ، کیونکہ اس سے انہیں اپنا کردار بہتر طریقے سے انجام دینے میں مدد مل سکتی ہے۔ POJO کلاس کی مثال :

public class User {
   private Long id;
   private String firstName;
   private String lastName;
   private Long age;

   public User(final Long id, final String firstName, final String lastName, final long age) {
       this.id = id;
       this.firstName = firstName;
       this.lastName = lastName;
       this.age = age;
   }

   public Long getId() {
       return this.id;
   }

   public String getFirstName() {
       return this.firstName;
   }

   public String getLastName() {
       return this.lastName;
   }

   public Long getAge() {
       return this.age;
   }

   @Override
   public boolean equals(final Object o) {
       if (this == o) return true;
       if (o == null || this.getClass() != o.getClass()) return false;
       final User user = (User) o;
       return Objects.equals(this.id, user.id) &&
               Objects.equals(this.firstName, user.firstName) &&
               Objects.equals(this.lastName, user.lastName) &&
               Objects.equals(this.age, user.age);
   }

   @Override
   public int hashCode() {
       return Objects.hash(this.id, this.firstName, this.lastName, this.age);
   }
}

26. کلاس میں کون سے عناصر شامل ہو سکتے ہیں؟

کلاس میں درج ذیل عناصر شامل ہو سکتے ہیں:

• کلاس فیلڈز؛
• جامد کلاس فیلڈز؛
• ابتدائی بلاک؛
• جامد ابتدائی بلاک؛
• کنسٹرکٹرز (خالی ہمیشہ ڈیفالٹ کے ذریعہ بیان کیا جاتا ہے)؛
• طریقے
• جامد طریقے؛
• مختلف تشریحات (جو خود کلاس یا اس کے اجزاء کے اوپر لٹک سکتی ہیں)؛
• عام _
• دوسرے طبقوں سے وراثت ( توسیع ) یا انٹرفیس ( آلوات ) سے عمل درآمد۔

27. جاوا میں وراثت کی وضاحت کریں۔ سپر کلیدی لفظ استعمال کرنے کے کیا فوائد ہیں؟

اوپر میں نے جاوا میں وراثت اور سپر کی ورڈ کے بارے میں پہلے ہی بات کی ہے۔ میں چند اور اہم نکات کا ذکر کرتا ہوں:

1. صرف ایک طبقے کا وارث ہونا ممکن ہے: جاوا میں ایک سے زیادہ وراثت نہیں ہے (لیکن جاوا 8 میں پہلے سے طے شدہ طریقوں کی آمد کے ساتھ، یہ بیان بہت متنازعہ ہو جائے گا)۔
2. پرائیویٹ طریقے اور فیلڈز بھی وراثت میں ملے ہیں، انہیں صرف وارث کی طرف سے ان تک رسائی حاصل نہیں ہوگی (لیکن اگر ہمارے پاس، مثال کے طور پر، ایک نجی فیلڈ ہے اور اس کے لیے عوامی یا محفوظ حاصل کرنے والے اور سیٹرز موجود ہیں، تو اس فیلڈ کے ساتھ کام کیا جا سکتا ہے۔ ان کے ذریعے)۔
3. آخری کلاسیں وراثت میں نہیں ملتی ہیں۔
4. حتمی طریقوں کو اوور رائڈ نہیں کیا جاتا ہے (لیکن وہ وراثت میں اور اوورلوڈ ہوسکتے ہیں)۔
5. جامد طریقے اور متغیرات وراثت میں نہیں ملے ہیں (چونکہ وہ اشیاء سے نہیں بلکہ کلاسوں سے منسلک ہیں)۔
6. تجریدی کلاسوں سے وراثت میں آتے وقت، ان کے تجریدی طریقوں کے نفاذ کی ضرورت ہوتی ہے، یا موجودہ کلاس کو بھی تجریدی قرار دیا جانا چاہیے۔
7. اگر والدین میں نان ڈیفالٹ کنسٹرکٹرز ہیں، تو انہیں چائلڈ کلاس میں اوور رائیڈ ہونا چاہیے (لیکن @Override ان پر نہیں لکھا جاتا)۔
8. ڈیسنڈنٹ میں اوور رائیڈڈ طریقوں کو رسائی موڈیفائر کے ساتھ بڑھایا جا سکتا ہے: نجی -> ڈیفالٹ -> محفوظ -> عوامی ۔
9. ڈیسنڈنٹ میں اوور رائیڈڈ طریقے لکھے گئے مستثنیات کو محدود کر سکتے ہیں، مثال کے طور پر: Exception -> IOException -> FileNotFoundException۔

28. طریقہ دستخط کیا ہے؟ صحیح اور غلط دستخطوں کی مثالیں دیں۔

ایک طریقہ کا دستخط طریقہ کا نام ہے اور آنے والے پیرامیٹرز کی اقسام (اور پیرامیٹرز کی ترتیب اہمیت رکھتی ہے)۔ طریقہ کے دستخط میں واپسی کی قیمت یا مستثنیات شامل نہیں ہیں جو اسے پھینکتے ہیں۔ صحیح دستخط کی مثال:

doSomething(int, double, double)

غلط دستخط کی ایک مثال:

void doSomething(int firstArg, int secondArg) throws Exception

طریقہ دستخط، واپسی کی قسم اور مستثنیات کی فہرست کے ساتھ مل کر، طریقہ معاہدہ کہلاتا ہے ۔ آج کیلئے بس اتنا ہی. بعد میں ملتے ہیں!