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

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

20. زبان کے کون سے عناصر encapsulation کو فعال کرتے ہیں؟

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

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

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

public class Lion extends Cat

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

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. زبان کے کون سے عناصر پولیمورفزم کے لیے ذمہ دار ہیں؟

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

public class Cat implements Animal

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

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

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

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

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

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

ایک POJO (Plain Old Java Object) ایک سادہ کلاس آبجیکٹ ہے جو کسی مخصوص طبقے سے وراثت میں نہیں آتا ہے اور کاروباری ماڈل کے لیے درکار سروس کے انٹرفیس سے ہٹ کر کوئی سروس انٹرفیس لاگو نہیں کرتا ہے۔ دوسرے لفظوں میں، POJO کلاس صرف ایک کلاس ہے جس کی کوئی خاص ضرورت نہیں ہے۔ ضرورت صرف ایک مخصوص فریم ورک سے منسلک مختلف گھنٹیوں اور سیٹیوں کی عدم موجودگی ہے۔ ایک اصول کے طور پر، یہ کلاسز دوسری کلاسوں کو وراثت میں نہیں ملتی ہیں ( ایک ہی پیکیج میں POJO کلاسوں کے علاوہ )، انٹرفیس کو لاگو نہیں کرتے ہیں (کبھی کبھی معیاری لائبریری سے مارکر انٹرفیس کے لیے استثناء کیا جاتا ہے جیسے Serializable یا Cloneable )، تشریحات کا استعمال نہ کریں۔ ، اور تیسری پارٹی کی لائبریریوں پر انحصار نہ کریں۔ آئیے نوٹ کریں کہ POJO میں کاروباری منطق اور کسی بھی قسم کے کنسٹرکٹرز پر مشتمل طریقے ہوسکتے ہیں۔ اگر ہم ان تشریحات کی اجازت دیتے ہیں جو کلاس کے سیمنٹکس کو تبدیل نہیں کرتے ہیں (یعنی تشریحات جن کی عدم موجودگی آبجیکٹ کے مقصد یا منطق کو تبدیل نہیں کرتی ہے)، تو POJO s میں JPA ہستیوں اور DTO آبجیکٹ کو بھی شامل کیا جا سکتا ہے جو XML یا JSON سے ڈی سیریلائز کیے گئے ہیں ، جن کے اصول ہیں۔ تشریحات میں بیان کیا گیا ہے۔ POJO کلاسز کے حوالے سے ذہن میں رکھنے کی ایک اور بات یہ ہے کہ ان کے مساوی اور ہیش کوڈ کے طریقوں کو اوور رائڈ کرنا اچھا ہے کیونکہ اس سے انہیں اپنے کردار کو بہتر طریقے سے نبھانے میں مدد مل سکتی ہے۔ 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. آپ رسائی موڈیفائر کو چائلڈ کلاس میں اوور رائیڈڈ طریقوں تک بڑھا سکتے ہیں: private -> default -> protected -> public ۔
وہ طریقے جو چائلڈ کلاس میں اوور رائڈ کیے گئے ہیں وہ کم استثنیٰ کو پھینک سکتے ہیں، مثال کے طور پر: Exception -> IOException -> FileNotFoundException۔

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

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

doSomething(int, double, double)

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

void doSomething(int firstArg, int secondArg) throws Exception

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