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

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

درمیانی

عام ہیں

1. طریقہ کار/فنکشنل پروگرامنگ کے مقابلے OOP کے کیا فوائد اور نقصانات ہیں؟

جونیئر کے سوالات کے تجزیہ میں یہ سوال تھا، اور اسی کے مطابق میں نے پہلے ہی اس کا جواب دیا ہے۔ اس سوال اور اس کا جواب مضمون کے اس حصے، سوالات 16 اور 17 میں دیکھیں ۔

2. جمع کرنا مرکب سے کیسے مختلف ہے؟

OOP میں، اشیاء کے درمیان تعامل کی کئی قسمیں ہیں، جو "Has-A Relationship" کے عمومی تصور کے تحت متحد ہیں۔ یہ تعلق اس بات کی نشاندہی کرتا ہے کہ ایک شے دوسری چیز کا جزو ہے۔ ایک ہی وقت میں، اس تعلق کی دو ذیلی قسمیں ہیں: مرکب - ایک شے دوسری چیز کو تخلیق کرتی ہے اور دوسری شے کی زندگی کا انحصار خالق کی زندگی پر ہے۔ ایگریگیشن - تعمیراتی عمل کے دوران ایک آبجیکٹ کو کسی دوسری چیز کا لنک (پوائنٹر) ملتا ہے (اس صورت میں، دوسری شے کی زندگی خالق کی زندگی پر منحصر نہیں ہے)۔ بہتر تفہیم کے لیے، آئیے ایک مخصوص مثال کو دیکھتے ہیں۔ ہمارے پاس کار کی ایک مخصوص کلاس ہے - کار ، جس کے نتیجے میں اس قسم کے اندرونی فیلڈز ہیں - انجن اور مسافروں کی فہرست - List<Passenger> ، اور اس میں حرکت شروع کرنے کا طریقہ بھی ہے - startMoving() :

public class Car {

 private Engine engine;
 private List<Passenger> passengers;

 public Car(final List<Passenger> passengers) {
   this.engine = new Engine();
   this.passengers = passengers;
 }

 public void addPassenger(Passenger passenger) {
   passengers.add(passenger);
 }

 public void removePassengerByIndex(Long index) {
   passengers.remove(index);
 }

 public void startMoving() {
   engine.start();
   System.out.println("Машина начала своё движение");
   for (Passenger passenger : passengers) {
     System.out.println("В машине есть пассажир - " + passenger.getName());
   }
 }
}

اس صورت میں، ساخت کار اور انجن کے درمیان تعلق ہے ، کیونکہ کار کی کارکردگی براہ راست انجن آبجیکٹ کی موجودگی پر منحصر ہے، کیونکہ اگر engine = null ، تو ہمیں ایک NullPointerException موصول ہوگا ۔ بدلے میں، ایک انجن بغیر مشین کے موجود نہیں ہو سکتا (ہمیں مشین کے بغیر انجن کی ضرورت کیوں ہے؟) اور ایک وقت میں کئی مشینوں سے تعلق نہیں رکھ سکتا۔ اس کا مطلب ہے کہ اگر ہم کار آبجیکٹ کو حذف کرتے ہیں، تو انجن آبجیکٹ کے حوالے سے مزید کوئی حوالہ نہیں ملے گا ، اور اسے جلد ہی گاربیج کلیکٹر کے ذریعے حذف کر دیا جائے گا ۔ جیسا کہ آپ دیکھ سکتے ہیں، یہ رشتہ بہت سخت (مضبوط) ہے۔ ایگریگیشن کار اور مسافر کے درمیان تعلق ہے ، کیونکہ کار کی کارکردگی کسی بھی طرح سے مسافر کی قسم کی اشیاء اور ان کی تعداد پر منحصر نہیں ہے۔ وہ یا تو کار کو چھوڑ سکتے ہیں - PassengerByIndex (Long index) کو ہٹا سکتے ہیں یا نئی داخل کر سکتے ہیں - addPassenger(Passenger مسافر) ، اس کے باوجود، گاڑی صحیح طریقے سے کام کرتی رہے گی۔ بدلے میں، مسافر اشیاء کار آبجیکٹ کے بغیر موجود ہوسکتی ہیں ۔ جیسا کہ آپ سمجھتے ہیں، یہ اس سے کہیں زیادہ کمزور کنکشن ہے جو ہم ساخت میں دیکھتے ہیں۔ لیکن یہ سب کچھ نہیں ہے، ایک آبجیکٹ جو جمع کے ذریعہ کسی دوسرے سے جڑا ہوا ہے اس کا وقت کے ساتھ ساتھ دوسری اشیاء کے ساتھ بھی دیا ہوا تعلق ہوسکتا ہے۔ مثال کے طور پر، آپ جاوا کے طالب علم کے طور پر، انگریزی، OOP اور لوگارتھمز کورسز میں ایک ہی وقت میں داخلہ لیتے ہیں، لیکن ساتھ ہی آپ ان کا انتہائی ضروری حصہ نہیں ہیں، جس کے بغیر عام کام کرنا ناممکن ہے (جیسے ایک استاد).

3. آپ نے عملی طور پر کون سے GoF پیٹرن استعمال کیے ہیں؟ مثالیں دیں۔

میں پہلے بھی اس سوال کا جواب دے چکا ہوں، اس لیے میں صرف تجزیہ کا لنک چھوڑ دوں گا ، پہلا سوال دیکھیں۔ مجھے ڈیزائن کے نمونوں پر ایک شاندار چیٹ شیٹ آرٹیکل بھی ملا ، جسے میں ہاتھ میں رکھنے کی انتہائی سفارش کرتا ہوں۔

4. پراکسی آبجیکٹ کیا ہے؟ مثالیں دیں۔

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

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

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

• سیکیورٹی پراکسی کے طور پر - استعمال کیا جاتا ہے جب آپ کو کلائنٹ کے حقوق کی بنیاد پر کسی چیز تک رسائی کو کنٹرول کرنے کی ضرورت ہوتی ہے۔ یعنی، اگر کوئی کلائنٹ جس میں رسائی کے حقوق موجود نہیں ہیں اصل آبجیکٹ تک رسائی حاصل کرنے کی کوشش کرتے ہیں، پراکسی اسے روک دے گی اور اسے اجازت نہیں دے گی۔

آئیے ایک ورچوئل پراکسی کی مثال دیکھیں: ہمارے پاس کچھ ہینڈلر انٹرفیس ہے:

public interface Processor {
 void process();
}

جس کے نفاذ میں بہت سارے وسائل استعمال ہوتے ہیں، لیکن ایک ہی وقت میں ہر بار ایپلیکیشن لانچ ہونے پر اسے استعمال نہیں کیا جا سکتا:

public class HiperDifficultProcessor implements Processor {
 @Override
 public void process() {
   // некоторый сверхсложная обработка данных
 }
}

پراکسی کلاس:

public class HiperDifficultProcessorProxy implements Processor {
private HiperDifficultProcessor processor;

 @Override
 public void process() {
   if (processor == null) {
     processor = new HiperDifficultProcessor();
   }
   processor.process();
 }
}

آئیے اسے مین میں چلائیں :

Processor processor = new HiperDifficultProcessorProxy();
// тут тяжеловсеного оригинального an object, ещё не сущетсвует
// но при этом есть an object, который его представляет и у которого можно вызывать его методы
processor.process(); // лишь теперь, an object оригинал был создан

میں نوٹ کرتا ہوں کہ بہت سے فریم ورک پراکسینگ کا استعمال کرتے ہیں، اور بہار کے لیے یہ ایک کلیدی نمونہ ہے (اسپرنگ کو اس کے اندر اور باہر سلائی کیا جاتا ہے)۔ اس پیٹرن کے بارے میں یہاں مزید پڑھیں ۔

5. جاوا 8 میں کن ایجادات کا اعلان کیا گیا ہے؟

Java 8 کی طرف سے لائی گئی اختراعات درج ذیل ہیں:

• فنکشنل انٹرفیس کو شامل کیا گیا ہے، اس کے بارے میں پڑھیں کہ یہ کس قسم کا جانور یہاں ہے ۔

• لیمبڈا ایکسپریشنز، جن کا فنکشنل انٹرفیس سے گہرا تعلق ہے، یہاں ان کے استعمال کے بارے میں مزید پڑھیں ۔

• ڈیٹا اکٹھا کرنے کی آسان پروسیسنگ کے لیے Stream API شامل کیا گیا ، یہاں مزید پڑھیں ۔

• طریقوں کے لنکس شامل کیے گئے ۔

• forEach() طریقہ کو Iterable انٹرفیس میں شامل کر دیا گیا ہے ۔

• java.time پیکیج میں ایک نئی تاریخ اور وقت کا API شامل کیا گیا، یہاں تفصیلی تجزیہ ۔

• بہتر کنکرنٹ API ۔

• اختیاری ریپر کلاس کو شامل کرنا ، جو کہ null اقدار کو درست طریقے سے ہینڈل کرنے کے لیے استعمال ہوتا ہے، آپ کو اس موضوع پر ایک بہترین مضمون یہاں مل سکتا ہے ۔

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

• Collection(removeIf(), spliterator()) کلاس میں نئے طریقے شامل کیے گئے ۔

• جاوا کور میں معمولی بہتری۔

6. اعلی ہم آہنگی اور کم جوڑے کیا ہیں؟ مثالیں دیں۔

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

public class User {
private String name;
private String email;

 public String getName() {
   return this.name;
 }

 public void setName(final String name) {
   this.name = name;
 }

 public String getEmail() {
   return this.email;
 }

 public void setEmail(final String email) {
   this.email = email;
 }

 public boolean isValidEmail() {
   // некоторая логика валидации емейла
 }
}

صارف کی کلاس صارف کے ای میل ایڈریس کو ذخیرہ کرنے کے لیے ذمہ دار ہو سکتی ہے، لیکن اس کی توثیق کرنے یا ای میل بھیجنے کے لیے نہیں۔ لہذا، اعلی ہم آہنگی حاصل کرنے کے لیے، ہم توثیق کے طریقہ کار کو ایک علیحدہ یوٹیلیٹی کلاس میں منتقل کرتے ہیں:

public class EmailUtil {
 public static boolean isValidEmail(String email) {
   // некоторая логика валидации емейла
 }
}

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

public class Student {
 private Long id;
 private String name;
 private List<Lesson> lesson;
}

جس میں اسباق کی فہرست ہے:

public class Lesson {
 private Long id;
 private String name;
 private List<Student> students;
}

ہر اسباق میں طلباء میں شرکت کا لنک ہوتا ہے۔ ناقابل یقین حد تک مضبوط گرفت، کیا آپ نہیں سوچتے؟ آپ اسے کیسے کم کر سکتے ہیں؟ سب سے پہلے، آئیے اس بات کو یقینی بنائیں کہ طلباء کے پاس مضامین کی فہرست نہیں ہے، بلکہ ان کے شناخت کنندگان کی فہرست ہے:

public class Student {
 private Long id;
 private String name;
 private List<Long> lessonIds;
}

دوسرا، سبق کی کلاس کو تمام طلباء کے بارے میں جاننے کی ضرورت نہیں ہے، لہذا آئیے ان کی فہرست کو یکسر حذف کر دیں:

public class Lesson {
 private Long id;
 private String name;
}

تو یہ بہت آسان ہو گیا، اور کنکشن بہت کمزور ہو گیا، کیا آپ نہیں سوچتے؟

او او پی

7. آپ جاوا میں ایک سے زیادہ وراثت کو کیسے نافذ کر سکتے ہیں؟

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

public interface Flyer {
 default void fly() {
   System.out.println("Я лечу!!!");
 }
}

واکر انٹرفیس، پہلے سے طے شدہ walk() طریقہ کے ساتھ :

public interface Walker {
 default void walk() {
   System.out.println("Я хожу!!!");
 }
}

تیراک انٹرفیس، swim() طریقہ کے ساتھ :

public interface Swimmer {
 default void swim() {
   System.out.println("Я плыву!!!");
 }
}

ٹھیک ہے، اب ہم ان سب کو ایک بطخ کلاس میں لاگو کرتے ہیں:

public class Duck implements Flyer, Swimmer, Walker {
}

اور آئیے اپنی بطخ کے تمام طریقے چلائیں:

Duck donald = new Duck();
donald.walk();
donald.fly();
donald.swim();

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

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

8. فائنل، فائنل اور فائنلائز() طریقوں میں کیا فرق ہے؟

فائنل ایک کلیدی لفظ ہے جو کلاس، طریقہ، یا متغیر پر رکاوٹ ڈالنے کے لیے استعمال ہوتا ہے، ایک رکاوٹ کا مطلب ہے:

• ایک متغیر کے لیے - ابتدائی آغاز کے بعد، متغیر کی نئی تعریف نہیں کی جا سکتی۔
• ایک طریقہ کے لیے، طریقہ کو ذیلی طبقے (جانشین کلاس) میں اوور رائڈ نہیں کیا جا سکتا۔
• کلاس کے لیے - کلاس کو وراثت میں نہیں مل سکتا۔

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