سست لوگوں کے لیے بہار فاؤنڈیشن، بنیادی تصورات، اور کوڈ کے ساتھ مثالیں۔ حصہ 1

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

بہار کا فریم ورک کیا ہے؟

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

ساخت

لیکن بہار صرف ایک خاص فریم ورک نہیں ہے۔ بلکہ، یہ ایک عام نام ہے جو کئی چھوٹے فریم ورک کا حوالہ دینے کے لیے استعمال ہوتا ہے، جن میں سے ہر ایک اپنی طرح کا کام کرتا ہے۔

https://docs.spring.io/spring/docs/4.3.26.RELEASE/spring-framework-reference/htmlsingle/
شکل 2.1۔ بہار کے فریم ورک کا جائزہ

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

• ڈیٹا تک رسائی
• ویب
• لازمی
• اور مزید

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

جاوا میں بہار کا فریم ورک کیوں ہے؟

ٹھیک ہے، اس حقیقت کے علاوہ کہ یہ فیشن ایبل، ہوشیار اور تازہ ہے، میں ابھی یہ کہہ سکتا ہوں کہ جیسے ہی آپ اسپرنگ کا استعمال کرتے ہوئے تھوڑی بہت مہارت حاصل کر لیں گے، آپ سمجھ جائیں گے کہ کس طرح ہر قسم کے کام ہیں جو آپ کے پاس نہیں ہیں۔ کرنا ہے، اور موسم بہار اپنے اوپر کتنا کام لیتا ہے۔ آپ کنفیگریشن سیٹنگز کی دو درجن لائنیں لکھ سکتے ہیں اور کچھ کلاسز لکھ سکتے ہیں، اور آپ ایک ورکنگ پروجیکٹ کے ساتھ ختم ہو جائیں گے۔ لیکن جیسے ہی آپ سوچنا شروع کریں گے کہ کتنی چیزیں زیر نگیں ہیں، کتنا کام کیا جا رہا ہے، اور اگر آپ سادہ سرولیٹس یا ساکٹ اور خالص جاوا پر مبنی اسی پروجیکٹ کو لاگو کرنے جارہے ہیں تو آپ کو کتنا کوڈ لکھنا پڑے گا، آپ کے بال سرے پر کھڑے ہوں گے :) بہار کو جادو کی ایک قسم کے طور پر بھی بیان کیا جاتا ہے۔ آپ کو اس کا تجربہ اس وقت ہوتا ہے جب آپ دیکھتے ہیں کہ سب کچھ کام کرتا ہے، لیکن آپ کو یہ بھی اندازہ ہوتا ہے کہ پردے کے پیچھے کیسے اور کتنا کام ہو رہا ہے — اس لیے ایسا لگتا ہے کہ عمل میں واقعی کوئی جادو ہے :) اسے جادو کہنا آسان ہے۔ یہ بتانے کی کوشش کرنے کے بجائے کہ یہ سب آپس میں کیسے جڑا ہوا ہے۔ :) Spring کے مطالعہ کے حق میں دوسری دلیل یہ ہے کہ جونیئر ڈویلپرز کے لیے تقریباً 90% ملازمتوں کے مواقع (میرے ذاتی مشاہدات کی بنیاد پر) کے لیے یا تو اس کے بارے میں علم یا کم از کم ایک عمومی خیال کی ضرورت ہوتی ہے کہ Spring's , , اور modules کیا پیش کرتے ہیں Dataنفیس Web MVCڈویلپرز Security:) لیکن آج صرف بنیادی باتوں کے بارے میں ہے۔

DI/IoC

اگر آپ نے کبھی بہار کے بارے میں پڑھنے کی کوشش کی ہے، تو سب سے پہلے آپ کا سامنا شاید یہ مخففات تھا: DI/IoC۔ اب میں انتہائی سفارش کرتا ہوں کہ آپ اس مضمون سے وقفہ لیں اور اس DZone مضمون کو پڑھیں ! IoC کا مطلب کنٹرول کے الٹا ہے۔ میں نے اس کا تذکرہ پہلے ہی گزرتے ہوئے کیا تھا جب میں نے لکھا تھا کہ لائبریری کے استعمال میں آپ خود اپنے کوڈ میں بتاتے ہیں کہ کس چیز پر کال کرنا ہے، لیکن فریم ورک کے استعمال کا عام طور پر مطلب یہ ہوتا ہے کہ فریم ورک آپ کے کوڈ کو صحیح وقت پر کال کرے گا۔ دوسرے لفظوں میں، اس مؤخر الذکر صورت میں، آپ کوڈ/پروگرام کو چلانے کے عمل کو مزید منظم نہیں کر رہے ہیں — فریم ورک آپ کے لیے ایسا کرتا ہے۔ آپ نے کنٹرول کو فریم ورک پر منتقل کیا (کنٹرول کا الٹا)۔ ڈی آئی کا مطلب انحصار انجیکشن ہے ۔ انحصار کے انجیکشن کے ساتھ، آپ بلی کی اشیاء کو مرکزی طریقہ میں نہیں بناتے ہیں اور پھر انہیں اپنے طریقوں پر منتقل کرتے ہیں۔ اس کے بجائے، بہار کا فریم ورک انہیں آپ کے لیے تخلیق کرتا ہے۔ آپ صرف کچھ ایسا کہتے ہیں جیسے "میں یہاں ایک بلی لانا چاہتا ہوں" اور فریم ورک آپ کے طریقہ کار میں آپ کو بھیجتا ہے۔ ہم اس مخفف کو آئندہ مضامین میں دیکھیں گے۔

پھلیاں اور سیاق و سباق

بہار کے اہم تصورات میں سے ایک بین ہے۔ درحقیقت یہ صرف کسی نہ کسی طبقے کا اعتراض ہے۔ فرض کریں کہ ہمارے پاس ایک پروگرام ہے جس میں 3 اشیاء کی ضرورت ہے: ایک بلی، ایک کتا، اور ایک طوطا۔ اور ہمارے پاس طریقوں کے ایک گروپ کے ساتھ کلاسوں کا ایک گروپ ہے۔ کبھی کبھی ہمیں کسی طریقے کے لیے بلی کی ضرورت ہوتی ہے، کبھی ہمیں کسی دوسرے طریقے کے لیے کتے کی ضرورت ہوتی ہے، اور کبھی کبھی ہمارے طریقوں کو بلی اور طوطے دونوں کی ضرورت ہوتی ہے (مثال کے طور پر، بلی کو کھانا کھلانے کا طریقہ، ہا ہا)۔ اب بھی دوسرے طریقوں کے لئے، تینوں اشیاء کی ضرورت ہے۔ جی ہاں، ہم سب سے پہلے ان تینوں اشیاء کو مین میتھڈ میں بنا سکتے ہیں، اور پھر انہیں اپنی کلاسز میں پاس کر سکتے ہیں، اور پھر ان کلاسز کے اندر ان کو متعلقہ طریقوں میں پاس کر سکتے ہیں... اور اسی طرح پورے پروگرام میں۔ لیکن اگر ہم یہ بھی فرض کریں کہ ہم کبھی کبھار اپنے طریقوں کے لیے ان پٹ پیرامیٹرز کی فہرست کو تبدیل کرنا چاہتے ہیں (مثال کے طور پر، ہم کسی چیز کو دوبارہ لکھنے یا نئی فعالیت شامل کرنے کا فیصلہ کرتے ہیں)، تو ہمیں کوڈ میں کافی تبدیلیاں کرنا ہوں گی۔ اور اب تصور کریں کہ ہمارے پاس 3 نہیں بلکہ 300 ایسی چیزیں ہیں۔ ایک متبادل یہ ہوگا کہ ہم اپنی تمام اشیاء کو ایک فہرست میں جمع کریں ( List<Object>)، اسے ہر طریقہ پر منتقل کریں، اور پھر طریقوں کے اندر رہتے ہوئے ضروری آبجیکٹ حاصل کریں۔ لیکن جیسے جیسے پروگرام چلتا ہے، اگر کوئی چیز اس فہرست میں شامل کر دی جائے، یا اس سے بھی بدتر، اگر کوئی حذف کر دیا جائے تو کیا ہوگا؟ اس میں ہر اس طریقہ کو توڑنے کی صلاحیت ہے جہاں ہم فہرست سے اشیاء حاصل کرنے کے لیے انڈیکس استعمال کرتے ہیں۔ اس مسئلے سے بچنے کے لیے، ہم اپنی اشیاء کو فہرست میں نہیں، بلکہ نقشے میں ذخیرہ کرنے کا فیصلہ کرتے ہیں، جہاں کلید آبجیکٹ کا نام ہے اور قدر خود آبجیکٹ ہے۔ یہ ہمیں ان اشیاء کو حاصل کرنے کی اجازت دیتا ہے جن کی ہمیں ضرورت ہوتی ہے صرف ان کے نام کا استعمال کرتے ہوئے، جیسے get("parrot")، اور جواب میں ہمیں طوطے کی چیز مل جاتی ہے۔ یا کلید آبجیکٹ کی کلاس ہو سکتی ہے، اور قدر خود آبجیکٹ ہو سکتی ہے۔ اس صورت میں، آبجیکٹ کا نام بتانے کے بجائے، لیکن صرف اس چیز کی کلاس کو مخصوص کر سکتے ہیں جس کی ہمیں ضرورت ہے۔ یہ بھی آسان ہے۔ یا ہم نقشے کے لیے کسی قسم کا ریپر بھی لکھ سکتے ہیں، جہاں کچھ طریقے اپنے نام سے اشیاء حاصل کرتے ہیں، اور دوسرے طریقے اپنی کلاس کے مطابق اشیاء حاصل کرتے ہیں۔ ہم یہاں تک جو پہنچے ہیں اس کو اسپرنگ فریم ورک میں ایپلیکیشن سیاق و سباق کہا جاتا ہے۔ سیاق و سباق پھلیاں (اشیاء) کا مجموعہ ہے۔ ہم ایک سیاق و سباق تک رسائی حاصل کرتے ہیں تاکہ ہمیں جس بین (آبجیکٹ) کی ضرورت ہو اس کے نام، اس کی قسم یا کسی اور ذریعہ سے۔ مزید برآں، ہم خود بہار سے کہہ سکتے ہیں کہ وہ اس کے اپنے سیاق و سباق میں اپنی ضرورت کے مطابق دیکھیں اور اسے ہمارے طریقہ کار پر منتقل کریں۔ مثال کے طور پر، فرض کریں کہ ہمارے پاس اس طرح کا طریقہ تھا:

public void doSomething(Cat cat) {
    ...
}

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

public void doSomething(Cat cat, Parrot parrot) {
    ...
}

اب جب اسپرنگ ہمارے طریقہ کار کو کال کرتا ہے، تو وہ بلی اور طوطے کو پاس کرنے کی ضرورت کو سمجھتا ہے، اس لیے وہ اس کے سیاق و سباق میں جاتا ہے، ان دو چیزوں کو حاصل کرتا ہے، اور انہیں ہمارے طریقہ کار پر منتقل کرتا ہے۔ کنٹرول کی لگام کو بہار میں منتقل کر کے، ہم اشیاء بنانے اور انہیں اپنے طریقوں میں منتقل کرنے کی ذمہ داری بھی منتقل کرتے ہیں، جسے بہار کہتے ہیں۔ اس سے سوال پیدا ہوتا ہے: بہار کیسے جانتی ہے کہ کون سی اشیاء ( پھلیاں) تخلیق کرنی ہیں؟

درخواست کو ترتیب دینے کے طریقے

ایک ایپلیکیشن کو ترتیب دینے کے تین اہم طریقے ہیں ، یعنی Spring کو یہ بتانے کے طریقے کہ ہمیں کن اشیاء کی ضرورت ہے:

1. XML کنفیگریشن فائلیں
2. جاوا پر مبنی ترتیب
3. خودکار ترتیب

بہار کے تخلیق کار انہیں اس ترتیب میں ترجیح دیتے ہیں:

• اولین ترجیح کے ساتھ طریقہ، جسے ترجیح دی جانی چاہیے، خودکار ترتیب ہے۔
• اگر خودکار کنفیگریشن کا استعمال تمام ممکنہ بینز کو درست طریقے سے کنفیگر کرنے کے لیے نہیں کیا جا سکتا ہے تو جاوا پر مبنی کنفیگریشن استعمال کریں (جس میں جاوا کوڈ کا استعمال کرتے ہوئے اشیاء بنانا شامل ہے)
• اور سب سے کم ترجیحی طریقہ پرانے زمانے کا طریقہ ہے - XML ​​config فائلوں کا استعمال۔

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