جاوا میں پیٹرن اور سنگلٹن

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

دنیا میں ایک ڈیزائن پیٹرن کیا ہے؟

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

ہمیں ڈیزائن پیٹرن کی ضرورت کیوں ہے؟

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

آخر میں، سنگلٹن پیٹرن

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

1. جب آپ کے پروگرام کی ضرورت ہوتی ہے کہ کسی خاص کلاس کے ایک سے زیادہ آبجیکٹ نہیں بنائے جائیں۔ مثال کے طور پر، کمپیوٹر گیم میں ہیرو کلاس ہو سکتی ہے اور صرف ایک ہیرو آبجیکٹ جو گیم میں واحد ہیرو کو بیان کرتا ہے۔


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

لہذا ایک سنگلٹن نے ان دو ضروریات کو پورا کیا: پروگرام میں صرف ایک خاص قسم کی چیز ہونی چاہیے اور اس تک عالمی رسائی ہونی چاہیے۔ لیول 15 کی مثال میں، کپتان آپ سے مندرجہ ذیل کام کے لیے اس پیٹرن کو نافذ کرنے کے لیے کہتا ہے:

1. سست ابتدا کے ساتھ سنگلٹن کی مثال تلاش کریں ۔

2. ایک ہی اصول کا استعمال کرتے ہوئے تین سنگلٹن کلاسز — سورج، چاند، زمین — الگ فائلوں میں بنائیں۔

3. نافذ کرناسیارہسورج ، چاند اور زمین کی کلاسوں میں انٹرفیس ۔

4. حل کلاس کے جامد بلاک میں کال کریں۔readKeyFromConsoleAndInitPlanetطریقہ

5. کو نافذ کریں۔readKeyFromConsoleAndInitPlanetطریقہ کار کی فعالیت:

   • 5.1 کنسول سے ایک سٹرنگ پیرامیٹر پڑھیں

   • 5.2 اگر پیرامیٹر ان میں سے کسی ایک کے برابر ہے۔سیارہانٹرفیس کے مستقل، مناسب دی پلینیٹ آبجیکٹ بنائیں۔

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

1. آپ کو کلاس کو ایک نجی جامد فیلڈ دینے کی ضرورت ہے جو ایک ہی چیز کو اسٹور کرتا ہے:

   public class LazyInitializedSingleton {
   	private static LazyInitializedSingleton instance; // #1
   }

2. (پہلے سے طے شدہ) کنسٹرکٹر کو نجی بنائیں۔ اس کا مطلب یہ ہے کہ اس تک کلاس سے باہر رسائی حاصل نہیں کی جاسکتی ہے اور وہ نئی اشیاء کو واپس نہیں کر سکے گا:

   public class LazyInitializedSingleton {
   	private static LazyInitializedSingleton instance;
   private LazyInitializedSingleton(){} // #2
   }

3. ایک جامد تخلیق کے طریقہ کار کا اعلان کریں جو سنگلٹن حاصل کرنے کے لیے استعمال کیا جائے گا:

   public class LazyInitializedSingleton {
       private static LazyInitializedSingleton instance;
           private LazyInitializedSingleton() {}
           public static LazyInitializedSingleton getInstance() { // #3
           if (instance == null) { // If the object has not yet been created
               instance = new LazyInitializedSingleton(); // Create a new object
           }
           return instance; // Return the previously created object
       }
   }

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

اور آخر کار... یہ سست ابتداء کیا ہے جس کے بارے میں کپتان نے پوچھا؟

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