جاوا ڊولپر لاءِ انٽرويوز کان سوالن ۽ جوابن جو تجزيو. حصو 11

سلام! ايستائين جو تيز ترين ٻيڙي بغير ڪنهن ڪورس جي صرف لهرن سان گڏ وهندي. جيڪڏهن توهان هاڻي منهنجو مضمون پڙهي رهيا آهيو، توهان وٽ ضرور هڪ مقصد آهي. اصلي شيء گمراھ ٿيڻ نه آھي، پر توھان جي لائين کي آخر تائين پيروي ڪرڻ - جاوا ڊولپر ٿيڻ لاء. اڄ مان جاوا ڊولپرز لاءِ 250+ سوالن جو منهنجو تجزيو جاري رکڻ چاهيان ٿو، جيڪو توهان جي نظريي جي ڪجهه خالن کي پورو ڪرڻ ۾ مدد ڪندو.

97. ڇا معاهدو ٻيهر بيان ڪرڻ جون شرطون لاڳو ڪيون وينديون آهن جڏهن برابري جي ٻيهر تعريف ڪجي؟

overrided equals() طريقو هيٺين شرطن (قاعدن) جي تعميل ڪرڻ گهرجي:

• reflexivity - ڪنهن به قدر x لاءِ، هڪ اظهار جهڙو x.equals(x) هميشه سچو موٽڻ گهرجي (جڏهن x != null ).

• symmetry - x ۽ y جي ڪنهن به قدر لاءِ، فارم x.equals(y) جو هڪ اظهار صرف سچو موٽڻ گهرجي جيڪڏهن y.equals(x) سچو موٽائي .

• transitivity - x ، y ۽ z جي ڪنهن به قدر لاءِ ، جيڪڏهن x.equals(y) سچو موٽائي ٿو ۽ y.equals(z) به سچو ڏي ٿو ، ته پوءِ x.equals(z) کي سچو موٽڻو پوندو .

• consistency - x ۽ y جي ڪنهن به قدر لاءِ ، x.equals(y) کي بار بار ڪال ڪرڻ سان هميشه پوئين ڪال جي قيمت هن طريقي ڏانهن موٽائي ويندي، بشرطيڪ ٻن شين جي مقابلي لاءِ استعمال ٿيل فيلڊ ڪالن جي وچ ۾ تبديل نه ٿين. .

• comparison null - ڪنهن به قدر x لاءِ، ڪال ڪرڻ سان x.equals(null) غلط موٽندو .

98. جيڪڏهن توهان Equals ۽ HashCode کي اوور رائڊ نه ڪندا ته ڇا ٿيندو؟

انهي صورت ۾، hashCode() هڪ نمبر ٺاهي ويندي جيڪا ميموري جي جڳهه تي ٻڌل آهي جنهن ۾ ڏنل اعتراض ذخيرو ٿيل آهي. اهو آهي، ٻه شيون بلڪل ساڳين فيلڊن سان مختلف قيمتون وصول ڪندا جڏهن هڪ غير اوور رائڊ ٿيل hashCode() کي سڏيندو (آخرڪار، اهي مختلف ميموري جڳهن ۾ محفوظ ٿيل آهن). unoverridden equals() حوالن جي ڀيٽ ڪري ٿو ته ڏسو ته اهي ساڳيا اعتراض ڏانهن اشارو ڪن ٿا يا نه. اهو آهي، مقابلو == ذريعي ڪيو ويو آهي ، ۽ ساڳئي شعبن سان شين جي صورت ۾ اهو هميشه غلط موٽندو . صحيح صرف تڏهن ٿيندو جڏهن ساڳئي اعتراض جي حوالن جي مقابلي ۾. ڪڏهن ڪڏهن انهن طريقن کي ختم نه ڪرڻ ۾ منطق آهي. مثال طور، توهان چاهيو ٿا ته هڪ خاص طبقي جون سڀئي شيون منفرد هجن ۽ انهن طريقن کي اوور رائيڊ ڪرڻ صرف انفراديت جي منطق کي خراب ڪندو. بنيادي شيء اها آهي ته اوور رائڊ ٿيل ۽ غير اوور رائڊ ٿيل طريقن جي نونسن کي سمجهڻ ۽ ٻنهي طريقن کي استعمال ڪرڻ جي صورتحال تي منحصر آهي.

99. جيڪڏهن x.equals(y) واپس اچي ته سميٽري صرف صحيح ڇو آهي؟

ڪجھ عجيب سوال. جيڪڏهن اعتراض A، اعتراض B جي برابر آهي، پوء اعتراض B اعتراض A جي برابر آهي. جيڪڏهن B اعتراض A جي برابر ناهي ته پوء مخالف ڪيئن ممڪن آهي؟ هي سادو منطق آهي.

100. HashCode ۾ ٽڪراءُ ڇا آهي؟ ان سان ڪيئن ڊيل ڪرڻ لاء؟

هڪ hashCode تصادم هڪ اهڙي صورتحال آهي جنهن ۾ ٻه مختلف شيون ساڳيون hashCode قدر آهن . اهو ڪيئن ممڪن آهي؟ حقيقت اها آهي ته هيشڪوڊ انٽيجر قسم تي ميپ ڪيو ويو آهي ، جنهن جي نتيجي ۾ -2147483648 کان 2147483647 تائين هڪ حد آهي، اهو آهي، تقريبن 4 بلين مختلف انٽيجرز. هي رينج تمام وڏو آهي، جڏهن ته، اهو لامحدود ناهي. تنهن ڪري، حالتون ممڪن آهن جڏهن ٻه مڪمل طور تي مختلف شيون ساڳيا هيش ڪوڊ آهن. اهو تمام گهڻو ممڪن ناهي، پر ممڪن آهي. هڪ خراب طريقي سان لاڳو ٿيل هيش فنڪشن هڪجهڙائي واري هيش ڪوڊس جي تعدد کي پڻ وڌائي سگھي ٿو، جيڪو مثال طور، واپسي نمبرن کي ننڍڙي رينج ۾ آڻيندو، جيڪو تصادم جو موقعو وڌائيندو. ٽڪراءَ کي منهن ڏيڻ لاءِ، توھان کي ھئش ڪوڊ جي طريقي تي سٺي عمل درآمد ڪرڻ جي ضرورت آھي ته جيئن قدرن جي پکيڙ وڌ ۾ وڌ ٿئي ۽ قدرن کي ورجائڻ جو موقعو گھٽ ۾ گھٽ ٿئي.

101. ڇا ٿيندو جيڪڏھن ھڪڙو عنصر جيڪو HashCode ڪانٽريڪٽ ۾ حصو وٺي پنھنجي قدر تبديل ڪري؟

جيڪڏهن هڪ عنصر جيڪو هش ڪوڊ جي ڳڻپ ۾ شامل آهي تبديل ڪيو ويو آهي، پوء اعتراض جو هيش ڪوڊ پاڻ کي تبديل ڪيو ويندو (جيڪڏهن هيش فنڪشن سٺو آهي). تنهن ڪري، 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 ۽ equals لاءِ غير پرائيميٽ فيلڊ چيڪ ڪرڻ ( اسٽرنگ ۾ طريقو اوور رائڊ ٿيل آهي ۽ صحيح نموني سان مقابلو ڪيو ويندو)، جيڪڏهن ٻئي فيلڊس null يا برابر آهن ، ته پوءِ چيڪ ختم ٿي وڃي ٿو ۽ طريقو سچو اچي ٿو .

هيش ڪوڊ:

• شروعاتي هيش ڪوڊ جي قيمت کي ترتيب ڏيڻ اعتراض جي عمر جي ابتدائي .

• موجوده هيش ڪوڊ کي 31 سان ضرب ڪرڻ (وڌيڪ اسپريڊ لاءِ) ۽ ان ۾ شامل ڪيو هيش ڪوڊ کي غير پرائمي اسٽرنگ فيلڊ جو (جيڪڏهن اهو null نه آهي).

• نتيجو موٽڻ.

• هن هيش ڪوڊ جي اوور رائڊ جي نتيجي ۾، ساڳي نالي سان شيون ۽ int ويلز هميشه ساڳي قدر واپس ڪندا.

103. if (Obj instanceof Student) ۽ if (getClass() == obj.getClass()) استعمال ڪرڻ ۾ ڇا فرق آهي؟

اچو ته ڏسو ته هر طريقو ڇا ڪري ٿو:

• instanceof چيڪ ڪري ٿو ته ڇا کاٻي پاسي واري اعتراض جو حوالو ساڄي پاسي واري قسم جو مثال آهي يا ان جو ڪجهه ذيلي قسم.

• getClass() == ... قسم جي سڃاڻپ لاءِ چيڪ ڪريو.

اهو آهي، جيڪڏهن getClass() ڪنهن طبقي جي مڪمل سڃاڻپ لاءِ چيڪ ڪري ٿو، ته پوءِ instanceof صحيح موٽندو جيتوڻيڪ اعتراض صرف هڪ ذيلي قسم آهي، جيڪو اسان کي وڌيڪ لچڪ ڏئي سگهي ٿو جڏهن فعال طور تي پوليمورفيزم استعمال ڪندي. دراصل، ٻئي طريقا سٺا آھن جيڪڏھن توھان انھن جي ڪم جي خصوصيتن کي سمجھو ۽ انھن کي صحيح جڳھن تي لاڳو ڪريو.

104. ڪلون () طريقي جي مختصر وضاحت ڏيو.

Clone() Object class جو هڪ طريقو آهي ، جنهن جو مقصد موجوده شئي جو ڪلون ٺاهڻ ۽ واپس ڪرڻ آهي (موجوده اعتراض جي ڪاپي). ان کي استعمال ڪرڻ لاء، توهان کي لاڳو ڪرڻ جي ضرورت آهي Cloneable مارڪر انٽرفيس :

Student implements Cloneable

۽ ڪلون () طريقو پاڻ کي ختم ڪريو :

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

سڀ کان پوء، اعتراض ڪلاس ۾ اهو محفوظ آهي، اهو آهي، اهو صرف شاگردن جي ڪلاس ۾ نظر ايندو ، پر ٻاهران طبقن کي نظر نه ايندو.

105. clone() طريقي جي خاصيت ڇا آهي جيڪو ڪنهن اعتراض جي قسم جي فيلڊ سان ڪم ڪري ٿو؟

جڏهن شيون ڪلون ڪري رهيا آهن، صرف ابتدائي قدر ۽ اعتراض جي حوالن جو قدر نقل ڪيو ويو آهي. ان جو مطلب اهو ٿيو ته جيڪڏهن ڪنهن شئي جي اندروني فيلڊ ۾ ڪنهن ٻئي شئي جو لنڪ هوندو ته پوءِ صرف اها لنڪ ڪلون ٿيندي، پر اها ٻي شئي پاڻ ڪلون نه ٿيندي. حقيقت ۾، اهو ئي آهي جنهن کي اهي سطحي ڪلوننگ سڏين ٿا. خير، ڇا جيڪڏھن توھان کي ضرورت آھي مڪمل ڪلوننگ سان گڏ سڀني اندر ٿيل شين جي ڪلوننگ؟ ڪيئن پڪ ڪجي ته اهي لنڪس جون ڪاپيون نه آهن، پر ڍير ۾ موجود ٻين ميموري سيلن سان گڏ شيون جا مڪمل کلون آهن؟ حقيقت ۾، هر شيء بلڪل سادو آهي - ان لاء توهان کي انهن اندروني شين جي هر ڪلاس ۾ clone() طريقي کي ختم ڪرڻ جي ضرورت آهي ۽ مارڪر انٽرفيس شامل ڪريو - Cloneable . پوءِ اهو حوالو نه هوندو ته شيون نقل ڪيون وينديون، پر شيون پاڻ، ڇاڪاڻ ته هاڻي اهي پڻ پاڻ کي نقل ڪرڻ جي صلاحيت رکن ٿا.

استثنا

106. نقص ۽ استثناءَ ۾ ڪهڙو فرق آهي؟

ٻئي استثنا ۽ غلطيون اڇلائي لائق طبقي جا ذيلي ڪلاس آھن . تنهن هوندي به، انهن جا پنهنجا اختلاف آهن. غلطي ھڪڙي مسئلي کي اشارو ڪري ٿو جيڪو خاص طور تي ناقص سسٽم وسيلن جي ڪري ٿئي ٿو. ۽ اسان جي ايپليڪيشن کي انهن قسمن جي مسئلن کي ڳولڻ نه گهرجي. غلطين جا ڪجهه مثال سسٽم حادثا ۽ ميموري جي غلطي کان ٻاهر آهن. غلطيون اڪثر ڪري رن ٽائم تي ٿينديون آهن جيئن اهي اڻ چيڪ ٿيل قسم جا آهن. استثنا اهي مسئلا آهن جيڪي رن ٽائم ۽ مرتب وقت تي ٿي سگهن ٿيون. عام طور تي اهو ڊولپرز طرفان لکيل ڪوڊ ۾ ٿئي ٿو. اهو آهي، استثنا وڌيڪ پيش گوئي وارا آهن ۽ ڊولپرز جي طور تي اسان تي وڌيڪ منحصر آهن. ساڳي ئي وقت، غلطيون اسان کان وڌيڪ بي ترتيب ۽ وڌيڪ آزاد آهن، بلڪه خود سسٽم جي مسئلن تي منحصر آهن جنهن ۾ اسان جي ايپليڪيشن هلندي آهي.

107. چيڪ ٿيل ۽ اڻ چيڪ ٿيل، استثنا، اڇلائڻ، اڇلائڻ ۾ ڪهڙو فرق آهي.

جيئن مون اڳ ۾ چيو آهي، هڪ استثنا پروگرام جي عمل جي دوران ۽ تاليف جي دوران هڪ غلطي آهي جيڪا ڊولپر طرفان لکيل ڪوڊ ۾ آئي آهي (ڪجهه غير معمولي صورتحال جي ڪري). چيڪ ڪيو ويو استثنا جو هڪ قسم آهي جنهن کي هميشه ڪوشش ڪرڻ واري ميڪانيزم کي استعمال ڪندي يا مٿي ڏنل طريقن ۾ اڇلائڻ گهرجي. اڇلائي استعمال ڪيو ويندو آهي طريقو هيڊر ۾ ممڪن استثنا ظاهر ڪرڻ لاءِ طريقي سان اڇلايل. اهو آهي، مٿي ڏنل طريقن ۾ "اُڇلڻ" استثناءَ جو هي ميکانيزم آهي. اڻ چيڪ ٿيل استثنا جو هڪ قسم آهي جنهن کي هٿ ڪرڻ جي ضرورت ناهي ۽ عام طور تي گهٽ پيش گوئي ۽ گهٽ ٿيڻ جو امڪان آهي. بهرحال، جيڪڏهن گهربل هجي، انهن کي پڻ پروسيس ڪري سگهجي ٿو. اڇلائڻ استعمال ڪيو ويندو آهي جڏهن هڪ استثنا دستي طور تي اڇلائي، مثال طور:

throw new Exception();

108. استثناءَ جو درجو ڇا آهي؟

استثناءَ جو درجو تمام وڏو ۽ وسيع آهي، ايستائين جو ان بابت سڀ ڪجهه هتي ٻڌائڻ لاءِ تمام وسيع آهي. تنهن ڪري، اسان صرف ان جي مکيه لنڪ تي غور ڪنداسين: هتي درجي بندي جي بلڪل چوٽي تي اسين ڏسون ٿا ڪلاس - اڇلائيبل - هڪ عام طبقو، استثنا واري درجه بندي جو آبائي، جنهن جي نتيجي ۾ ورهايل آهي:

• نقص - نازڪ، اڻ چيڪ ٿيل غلطيون.
• استثنا - چڪاس ٿيل استثنا.

استثنا مختلف غير چيڪ ٿيل رن ٽائم استثنا ۽ مختلف چيڪ ٿيل استثنان ۾ ورهايل آهي.

109. چيڪ ٿيل ۽ اڻ چيڪ ٿيل استثنا ڇا آهي؟

جيئن مون اڳ چيو:

• چيڪ ڪيو ويو آهي - استثنا جيڪي توهان کي ڪنهن نه ڪنهن طريقي سان سنڀالڻ گهرجن، اهو آهي، يا ته انهن کي ڪوشش ۾ پروسيس ڪريو - ڪيچ بلاڪ ، يا "اڳتي" انهن کي مٿين طريقي سان. هن کي ڪرڻ لاء، طريقي جي دستخط ۾، طريقي جي دليلن کي لسٽ ڪرڻ کان پوء، توهان کي استعمال ڪرڻ جي ضرورت آهي trows <exception type> keyword ، جيڪو طريقو جي استعمال ڪندڙن ڏانهن اشارو ڪري ٿو ته طريقو هن استثنا کي اڇلائي سگهي ٿو (ڪجهه ڊيڄاريندڙ وانگر) ۽ منتقلي ڪري ٿو. هن طريقي جي استعمال ڪندڙن جي استثنا کي سنڀالڻ جي ذميواري.

• اڻ چيڪ ٿيل - استثنا جيڪي هٿ ڪرڻ جي ضرورت نه آهي، ڇاڪاڻ ته اهي مرتب وقت تي چيڪ نه ڪيا ويا آهن ۽، ضابطي جي طور تي، وڌيڪ غير متوقع آهن. اهو آهي، چيڪ ڪرڻ سان بنيادي فرق اهو آهي ته انهن لاء اهي ڪوشش-پڪڙ يا اڇلائڻ وارا ميڪانيزم ساڳيو ڪم ڪن ٿا، پر اهي لازمي نه آهن.

101. ڪنهن طريقي جي ڪوشش-ڪيچ بلاڪ ۾ هڪ استثنا کي مداخلت ڪرڻ ۽ هٿ ڪرڻ جو هڪ مثال لکو

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

102. پنھنجي استثنا کي استعمال ڪندي ھڪڙي استثنا کي پڪڙڻ ۽ ھٿ ڪرڻ جو ھڪڙو مثال لکو

پهرين، اچو ته اسان جو پنهنجو استثنا ڪلاس لکون، جيڪو استثنا مان ورثي ۾ ملي ٿو ۽ ان جي تعمير ڪندڙ کي غلطي واري پيغام سان ختم ڪري ٿو:

public class CustomException extends Exception {

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

خير، پوءِ اسان ان کي دستي طور اڇلينداسين ۽ ان کي روڪينداسين جيئن پوئين سوال ۾:

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

۽ ٻيهر، جڏهن توهان ان کي هلائيندا آهيو، توهان ڪنسول ڏانهن هيٺين آئوٽ حاصل ڪندا: توھان حاصل ڪري سگھو ٿا وڌيڪ استثناء بابت هتي . خير، اهو سڀ ڪجهه اڄ لاء آهي! ايندڙ حصي ۾ ملنداسين!