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

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

97. کیا Equals کی دوبارہ تعریف کرتے وقت معاہدے کی دوبارہ تعریف کی شرائط عائد کی جاتی ہیں؟

overrided equals() طریقہ کو درج ذیل شرائط (قواعد) کی تعمیل کرنی چاہیے:

• اضطراری صلاحیت - کسی بھی قدر 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 - کسی بھی قدر x کے لیے، x.equals(null) کو کال کرنے سے غلط واپس آئے گا ۔

98. اگر آپ Equals اور HashCode کو اوور رائڈ نہیں کرتے ہیں تو کیا ہوگا؟

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

99. توازن صرف درست کیوں ہے اگر x.equals(y) صحیح لوٹتا ہے؟

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

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

ہیش کوڈ کا تصادم ایک ایسی صورتحال ہے جس میں دو مختلف اشیاء کی ہیش کوڈ کی قدر ایک جیسی ہوتی ہے ۔ یہ کیسے ممکن ہے؟ حقیقت یہ ہے کہ ہیش کوڈ کو Integer قسم میں میپ کیا گیا ہے ، جس کی رینج -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 یا کسی اور قسم کی دلیل ہے، تو اس کا مطلب ہے کہ اشیاء برابر نہیں ہیں - false ۔

• دلیل آبجیکٹ کو ایک قسم پر ڈالنا (اگر یہ بنیادی قسم کا اعتراض تھا)۔

• ایک پرائمیٹو کلاس فیلڈ کا موازنہ (آخر کار، موازنہ کے ذریعے =! اس کے لیے کافی ہے )، اگر فیلڈ برابر نہیں ہے - غلط ۔

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

ہیش کوڈ:

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

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

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

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

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

آئیے دیکھتے ہیں کہ ہر ایک نقطہ نظر کیا کرتا ہے:

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

• getClass() == ... قسم کی شناخت کی جانچ کرتا ہے۔

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

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

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

Student implements Cloneable

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

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

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

105. کلون() طریقہ کار کی خاصیت کیا ہے جو کسی آبجیکٹ آف ریفرنس ٹائپ کے فیلڈز کے ساتھ کام کرتی ہے؟

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

مستثنیات

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

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

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

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

throw new Exception();

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

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

• خرابی - اہم، غیر چیک کرنے والی غلطیاں۔
• استثناء - مستثنیات کو چیک کیا گیا۔

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

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

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

• چیک کیا گیا - مستثنیات جو آپ کو کسی نہ کسی طرح ہینڈل کرنا ہوں گی، یعنی یا تو ان کو آزما کر کارروائی کریں - catch block ، یا انہیں اوپر والے طریقہ پر "فارورڈ" کریں۔ ایسا کرنے کے لیے، طریقہ کار کے دستخط میں، طریقہ کار کے دلائل درج کرنے کے بعد، آپ کو trows <exception type> کلیدی لفظ استعمال کرنے کی ضرورت ہے، جو کہ طریقہ استعمال کرنے والوں کو اشارہ کرتا ہے کہ طریقہ اس استثنا کو پھینک سکتا ہے (انتباہ جیسی کوئی چیز) اور منتقلی اس طریقہ کار کے استعمال کنندگان کے استثنا کو سنبھالنے کی ذمہ داری۔

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

101. کسی طریقہ کے ٹرائی کیچ بلاک میں استثنیٰ کو روکنے اور ہینڈل کرنے کی ایک مثال لکھیں

try{                                                 // начало блока перехвата
 throw new Exception();                             // ручной бросок исключения
} catch (Exception e) {                              // данное исключение и его потомки будут перехватываться
 System.out.println("Упс, что-то пошло не так =("); // вывод некоторого исключения в консоль
}

102. اپنے استثناء کا استعمال کرتے ہوئے کسی استثناء کو پکڑنے اور سنبھالنے کی ایک مثال لکھیں۔

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

public class CustomException extends Exception {

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

ٹھیک ہے، پھر ہم اسے دستی طور پر پھینک دیں گے اور پچھلے سوال کی طرح اسے روکیں گے:

try{
 throw new CustomException("Упс, что-то пошло не так =(");
} catch (CustomException e) {
 System.out.println(e.getMessage());
}

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