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

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

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

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

ساخت

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

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

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

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

ٹھیک ہے، اس حقیقت کے علاوہ کہ یہ فیشن ایبل، اسٹائلش اور جوان ہے، میں فوری طور پر کہہ سکتا ہوں کہ جیسے ہی آپ اس میں تھوڑی سی مہارت حاصل کر لیں گے، آپ سمجھ جائیں گے کہ اب آپ کو کتنے مختلف کام کرنے کی ضرورت نہیں ہے، اور کتنی بہاریں ہیں۔ پر لیتا ہے. آپ کنفیگس کی کچھ درجن لائنیں لکھ سکتے ہیں، کچھ کلاسیں لکھ سکتے ہیں - اور آپ کو ایک کام کرنے والا پروجیکٹ ملے گا۔ لیکن جیسے ہی آپ یہ سوچنا شروع کرتے ہیں کہ "ہڈ کے نیچے" کتنا ہے، کتنا کام ہو رہا ہے، اور کتنا کوڈ لکھنا پڑے گا اگر آپ وہی پروجیکٹ ننگے سرولیٹ یا ساکٹ اور خالص جاوا پر کرتے ہیں۔ - آپ کے بال سرے پر کھڑے ہیں :) یہاں تک کہ اس طرح کا اظہار بھی ہے، جیسا کہ بہار کا "جادو"۔ ایسا اس وقت ہوتا ہے جب آپ دیکھتے ہیں کہ سب کچھ کام کر رہا ہے، لیکن آپ اندازہ لگاتے ہیں کہ وہاں ہر چیز کے کام کرنے کے لیے کتنا ہونا ضروری ہے اور وہاں یہ سب کیسے کام کرتا ہے - پھر ایسا لگتا ہے کہ یہ سب کچھ واقعی کسی جادو کی بدولت ہو رہا ہے)) یہ آسان ہے۔ یہ سب کچھ جادو کہنے کے بجائے یہ بتانے کی کوشش کریں کہ یہ سب وہاں کیسے ایک دوسرے سے جڑا ہوا ہے۔ مسکراہٹ data_ web-mvc_ security_ صرف بنیادی باتیں۔

DI/IoC

اگر آپ نے بہار پر کچھ پڑھنے کی کوشش کی، تو سب سے پہلے جو چیز آپ کو ملی وہ شاید یہ حروف تھے: DI/IoC ۔ اب میں انتہائی سفارش کرتا ہوں کہ آپ اس مضمون سے وقفہ لیں اور Habré پر اس مضمون کو پڑھیں ! آئی او سی (کنٹرول کا الٹا) - کنٹرول کا الٹا۔ اس کا ذکر میں نے گزرتے ہوئے پہلے ہی کیا تھا جب میں نے لکھا تھا کہ لائبریری کا استعمال کرتے وقت آپ خود اپنے کوڈ میں لکھتے ہیں کہ کس چیز کو کال کرنا ہے اور فریم ورک کے معاملے میں اکثر فریم ورک اس کوڈ کو کال کرے گا جو آپ نے دائیں طرف لکھا ہے۔ لمحہ. یعنی، یہاں آپ کوڈ/پروگرام پر عمل درآمد کے عمل کو مزید کنٹرول نہیں کرتے، لیکن فریم ورک آپ کے لیے کرتا ہے۔ آپ نے اس کو کنٹرول منتقل کر دیا (کنٹرول کا الٹا)۔ DI کو یا تو Dependency Inversion کے طور پر سمجھا جاتا ہے (انحصار الٹا، یعنی آپ کے ماڈیولز/کلاسز کے درمیان سخت کنکشن نہ بنانے کی کوشش کرتا ہے، جہاں ایک کلاس براہ راست دوسری کلاس سے منسلک ہوتی ہے) یا Dependency Injection (انحصار انجکشن، یہ تب ہوتا ہے جب بلی کی اشیاء نہ ہوں۔ مین میں آپ کے ذریعہ تخلیق کیا جاتا ہے اور پھر آپ انہیں اپنے طریقوں پر منتقل کرتے ہیں، اور بہار انہیں آپ کے لیے تخلیق کرتی ہے، اور آپ اسے صرف کچھ ایسا کہتے ہیں جیسے "میں یہاں ایک بلی لانا چاہتا ہوں" اور وہ اسے آپ کے طریقہ کار میں آپ کو دے دیتا ہے)۔ ہم مزید مضامین میں اکثر دوسرے کا سامنا کریں گے۔

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

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

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

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

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

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

ایپلیکیشن کنفیگریشن کے طریقے

ایپلیکیشن کو کنفیگر کرنے کے تین اہم طریقے ہیں (یعنی Spring کو بتائیں کہ ہمیں کن چیزوں پر کام کرنے کی ضرورت ہے):

1. ایکس ایم ایل فائلوں / تشکیلات کا استعمال کرتے ہوئے؛
2. java configs کا استعمال کرتے ہوئے؛
3. خودکار ترتیب.

بہار کے ڈویلپرز انہیں ترجیح کے اس ترتیب میں ترتیب دیتے ہیں:

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

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