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

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

97. کیا مساوی () کو اوور رائیڈ کرنے پر کوئی اصول لاگو ہوتے ہیں؟

Equals() طریقہ کو اوور رائیڈ کرتے وقت، آپ کو درج ذیل اصولوں کی تعمیل کرنی ہوگی۔

• reflexivity — کسی بھی قدر کے لیے x ، x.equals(x) کو ہمیشہ درست لوٹنا چاہیے (جہاں x != null )۔

• ہم آہنگی — کسی بھی قدر کے لیے x اور y ، x.equals(y) کو صحیح لوٹنا چاہیے تبھی اگر y.equals(x) صحیح لوٹاتا ہے ۔

• transitivity — کسی بھی قدروں کے لیے x ، y اور z ، اگر x.equals(y) صحیح لوٹاتا ہے اور y.equals(z) بھی true لوٹاتا ہے ، تو x.equals(z) کو true لوٹنا چاہیے ۔

• مستقل مزاجی — کسی بھی قدر کے لیے x اور y ، بار بار x.equals(y) کو کال کرنے سے ہمیشہ ایک ہی قدر واپس آئے گی جب تک کہ دو اشیاء کا موازنہ کرنے کے لیے استعمال ہونے والے فیلڈز ہر کال کے درمیان تبدیل نہ ہوں۔

• null comparison — کسی بھی قدر x کے لیے ، x.equals(null) کو کال کرنے پر غلط لوٹنا چاہیے ۔

98. اگر آپ equals() اور hashCode() کو اوور رائڈ نہیں کرتے ہیں تو کیا ہوگا؟

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

99. توازن کی ضرورت صرف اس صورت میں کیوں پوری ہوتی ہے جب x.equals(y) درست ہو؟

یہ سوال قدرے عجیب ہے۔ اگر اعتراض A اعتراض B کے برابر ہے، تو اعتراض B اعتراض A کے برابر ہے، اگر B اعتراض A کے برابر نہیں ہے، تو پھر الٹ کیسے ممکن ہے؟ یہ کامن سینس ہے۔

100. ہیش کوڈ کا تصادم کیا ہے؟ آپ اس سے کیسے نمٹتے ہیں؟

HashCode کا تصادم اس وقت ہوتا ہے جب دو مختلف اشیاء میں ایک ہی HashCode ہو ۔ یہ کیسے ممکن ہے؟ ٹھیک ہے، ہیش کوڈ ایک انٹیجر میں میپ ہو جاتا ہے، جس کی رینج -2147483648 سے 2147483647 تک ہوتی ہے۔ یعنی یہ تقریباً 4 بلین مختلف انٹیجرز میں سے ایک ہو سکتا ہے۔ یہ سلسلہ بہت بڑا ہے لیکن لامحدود نہیں۔ اس کا مطلب ہے کہ ایسے حالات ہیں جب دو بالکل مختلف اشیاء میں ایک ہیش کوڈ ہو سکتا ہے۔ اس کا امکان بہت کم ہے، لیکن یہ ممکن ہے۔ ایک ناقص طور پر لاگو کیا گیا ہیش فنکشن ایک چھوٹی رینج میں نمبر واپس کر کے ایک جیسے ہیش کوڈز کو زیادہ بار بار بنا سکتا ہے، اس طرح تصادم کا امکان بڑھ جاتا ہے۔ تصادم کو کم کرنے کے لیے، آپ کو ہیش کوڈ کے طریقہ کار کا ایک اچھا نفاذ کرنے کی ضرورت ہے جو قدروں کو یکساں طور پر پھیلاتا ہے اور بار بار اقدار کے امکانات کو کم کرتا ہے۔

101. اگر ہیش کوڈ کنٹریکٹ میں حصہ لینے والے عنصر کی قدر بدل جائے تو کیا ہوگا؟

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

102. ایک سٹوڈنٹ کلاس کے لیے equals() اور hashCode() طریقے لکھیں جس میں String name اور int age فیلڈز ہوں۔

public class Student {
int age;
String name;

 @Override
 public boolean equals(final Object o) {
   if (this == o) {
     return true;
   }
   if (o == null || this.getClass() != o.getClass()) {
     return false;
   }

   final Student student = (Student) o;

   if (this.age != student.age) {
     return false;
   }
   return this.name != null ? this.name.equals(student.name) : student.name == null;
 }

 @Override
 public int hashCode() {
   int result = this.age;
   result = 31 * result + (this.name != null ? this.name.hashCode() : 0);
   return result;
 }
}

برابر():

• سب سے پہلے، ہم حوالہ جات کا براہ راست موازنہ کرتے ہیں، کیونکہ اگر حوالہ جات ایک ہی چیز کی طرف اشارہ کرتے ہیں، تو برابری کی جانچ جاری رکھنے میں کیا فائدہ ہے؟ ہم پہلے ہی جانتے ہیں کہ نتیجہ درست ہو گا ۔

• ہم null کی جانچ کرتے ہیں اور آیا کلاس کی اقسام ایک جیسی ہیں کیونکہ اگر پیرامیٹر null ہے یا کسی اور قسم کا، تو اشیاء برابر نہیں ہو سکتیں، اور نتیجہ غلط ہونا چاہیے ۔

• ہم پیرامیٹر کو ایک ہی قسم میں ڈالتے ہیں (آخر، کیا ہوگا اگر یہ پیرنٹ قسم کی کوئی چیز ہے)۔

• ہم قدیم فیلڈز کا موازنہ کرتے ہیں ( =! کا استعمال کرتے ہوئے ایک موازنہ کافی ہوگا)۔ اگر وہ برابر نہیں ہیں تو، ہم جھوٹے واپس آتے ہیں .

• ہم غیر قدیم فیلڈ کو یہ دیکھنے کے لیے چیک کرتے ہیں کہ آیا یہ کالعدم ہے اور مساوی طریقہ استعمال کر رہا ہے ( اسٹرنگ کلاس طریقہ کو اوور رائیڈ کرتا ہے، لہذا یہ موازنہ کو صحیح طریقے سے انجام دے گا)۔ اگر دونوں فیلڈز null ہیں، یا مساوی واپسی true ، تو ہم چیک کرنا بند کر دیتے ہیں، اور طریقہ واپس آتا ہے true ۔

ہیش کوڈ() :

• ہم نے ہیش کوڈ کی ابتدائی قدر آبجیکٹ کی عمر والے فیلڈ کی قدر کے برابر مقرر کی ہے۔

• ہم موجودہ ہیش کوڈ کو 31 سے ضرب دیتے ہیں (اقدار میں زیادہ پھیلاؤ کے لیے) اور پھر غیر قدیم سٹرنگ فیلڈ کا ہیش کوڈ شامل کرتے ہیں (اگر یہ کالعدم نہیں ہے)۔

• ہم نتیجہ واپس کرتے ہیں۔

• طریقہ کو اس طرح اوور رائیڈ کرنے کا مطلب ہے کہ ایک جیسے نام اور int ویلیوز والی اشیاء ہمیشہ ایک ہی ہیش کوڈ کو واپس کریں گی۔

103. "if (obj instanceof Student)" اور "if (getClass() == obj.getClass())" کے استعمال میں کیا فرق ہے؟

آئیے ایک نظر ڈالتے ہیں کہ ہر ایک اظہار کیا کرتا ہے:

• instanceof چیک کرتا ہے کہ آیا بائیں طرف آبجیکٹ کا حوالہ دائیں طرف کی قسم کی مثال ہے یا اس کی ذیلی قسموں میں سے ایک ہے۔

• "getClass() == ..." چیک کرتا ہے کہ آیا اقسام ایک جیسی ہیں۔

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

104. clone() طریقہ کی ایک مختصر وضاحت دیں۔

کلون () طریقہ آبجیکٹ کلاس سے تعلق رکھتا ہے۔ اس کا مقصد موجودہ آبجیکٹ کا کلون (کاپی) بنانا اور واپس کرنا ہے۔ اس طریقہ کو استعمال کرنے کے لیے، آپ کو Cloneable مارکر انٹرفیس کو لاگو کرنے کی ضرورت ہے:

Student implements Cloneable

اور کلون() طریقہ کو ہی اوور رائیڈ کریں:

@Override
protected Object clone() throws CloneNotSupportedException {
 return super.clone();
}

سب کے بعد، یہ آبجیکٹ کلاس میں محفوظ ہے ، یعنی یہ صرف اسٹوڈنٹ کلاس میں نظر آئے گا اور بیرونی کلاسوں میں نظر نہیں آئے گا۔

105. کلون() طریقہ کار اور کسی چیز میں حوالہ متغیر کے حوالے سے آپ کو کن خاص باتوں کو ذہن میں رکھنے کی ضرورت ہے؟

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

مستثنیات

106. غلطی اور استثناء میں کیا فرق ہے؟

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

107. چیک شدہ، غیر چیک شدہ، استثنیٰ، تھرو، اور تھرو میں کیا فرق ہے؟

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

throw new Exception();

108. استثنائی درجہ بندی کیا ہے؟

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

• غلطیاں - اہم، غیر چیک شدہ مسائل۔
• مستثنیات - مستثنیات جن کی جانچ کی جاسکتی ہے۔

مستثنیات کو مختلف غیر چیک شدہ رن ٹائم مستثنیات اور مختلف چیک شدہ مستثنیات میں تقسیم کیا گیا ہے۔

109. چیک شدہ اور غیر چیک شدہ مستثنیات کیا ہیں؟

جیسا کہ میں نے پہلے کہا:

• چیک شدہ مستثنیات مستثنیات ہیں جنہیں آپ کو کسی نہ کسی طرح ہینڈل کرنا ہوگا۔ یعنی، آپ کو یا تو انہیں ٹرائی کیچ بلاک میں ہینڈل کرنا چاہیے یا انہیں اوپر والے طریقہ پر پھینک دینا چاہیے۔ ایسا کرنے کے لیے، طریقہ کے دستخط میں طریقہ کار کے دلائل درج کرنے کے بعد، تھرو <exception type> کا استعمال کریں تاکہ یہ ظاہر کیا جا سکے کہ طریقہ اس استثنا کو پھینک سکتا ہے۔ یہ کسی حد تک ایک انتباہ کی طرح ہے، کال کرنے کے طریقہ کار کو نوٹس پر ڈالتا ہے کہ اسے اس استثناء کو سنبھالنے کی ذمہ داری قبول کرنی ہوگی۔

• غیر چیک شدہ مستثنیات کو سنبھالنے کی ضرورت نہیں ہے، کیونکہ وہ مرتب وقت پر چیک نہیں کیے جاتے ہیں اور عام طور پر زیادہ غیر متوقع ہوتے ہیں۔ چیک شدہ مستثنیات کے ساتھ ان کا بنیادی فرق یہ ہے کہ ٹرائی کیچ بلاک کا استعمال کرکے یا دوبارہ پھینک کر ان کو سنبھالنا لازمی کی بجائے اختیاری ہے۔

101. ایک مثال لکھیں جہاں آپ ایک استثناء کو پکڑنے اور سنبھالنے کے لیے ٹرائی کیچ بلاک استعمال کرتے ہیں۔

try{                                                 // Start of the try-catch block
 throw new Exception();                             // Manually throw an exception
} catch (Exception e) {                              // Exceptions of this type and its subtypes will be caught
 System.out.println("Oops! Something went wrong =("); // Display the exception
}

102. ایک مثال لکھیں جہاں آپ اپنی مرضی کے مستثنیات کو پکڑتے اور سنبھالتے ہیں۔

سب سے پہلے، ہم اپنی اپنی استثنائی کلاس لکھتے ہیں جو Exception کو وراثت میں ملتی ہے اور اس کے کنسٹرکٹر کو اوور رائیڈ کرتے ہیں جو ایک ایرر میسج کو بطور دلیل لیتا ہے:

public class CustomException extends Exception {

 public CustomException(final String message) {
   super(message);
 }
}

اگلا ہم دستی طور پر ایک پھینکیں گے اور اسے پکڑیں ​​گے جیسا کہ ہم نے پچھلے سوال کی مثال میں کیا تھا۔

try{
 throw new CustomException("Oops! Something went wrong =(");
} catch (CustomException e) {
 System.out.println(e.getMessage());
}

ایک بار پھر، جب ہم اپنا کوڈ چلاتے ہیں، تو ہمیں درج ذیل آؤٹ پٹ ملتا ہے: ٹھیک ہے، یہ سب آج کے لئے ہے! اگلے حصے میں ملتے ہیں!