کوڈنگ کے اصول: سسٹم بنانے سے لے کر آبجیکٹ کے ساتھ کام کرنے تک

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

سسٹمز

مندرجہ ذیل عام طور پر ایک نظام کی مطلوبہ خصوصیات ہیں:

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

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

تصویری ماخذ

سسٹم ڈیزائن کرنے کے مراحل

1. سافٹ ویئر سسٹم۔ ایپلیکیشن کو مجموعی طور پر ڈیزائن کریں۔
2. سب سسٹمز/پیکیجز میں تقسیم۔ منطقی طور پر الگ الگ حصوں کی وضاحت کریں اور ان کے درمیان تعامل کے قواعد کی وضاحت کریں۔
3. ذیلی نظاموں کی کلاسوں میں تقسیم۔ سسٹم کے حصوں کو مخصوص کلاسوں اور انٹرفیس میں تقسیم کریں، اور ان کے درمیان تعامل کی وضاحت کریں۔
4. طریقوں میں کلاسوں کی تقسیم۔ کلاس کے لیے اس کی تفویض کردہ ذمہ داری کی بنیاد پر ضروری طریقوں کی مکمل تعریف بنائیں۔
5. طریقہ کار ڈیزائن۔ انفرادی طریقوں کی فعالیت کی تفصیلی تعریف بنائیں۔

عام طور پر عام ڈویلپر اس ڈیزائن کو ہینڈل کرتے ہیں، جبکہ ایپلی کیشن کا آرکیٹیکٹ اوپر بیان کردہ پوائنٹس کو ہینڈل کرتا ہے۔

نظام کے ڈیزائن کے عمومی اصول اور تصورات

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

اے او پی

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

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

ٹھوس

ایک نظام کو ڈیزائن کرتے وقت، معروف SOLID اصولوں پر غور کرنا ضروری ہے:

S (سنگل ذمہ داری)، O (اوپن-کلوزڈ)، L (لیسکوف متبادل)، I (انٹرفیس سیگریگیشن)، D (انحصار الٹا)۔

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

انٹرفیس

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

کلاس

تصویری ماخذ

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

1. عوامی جامد مستقل؛
2. نجی جامد مستقل؛
3. نجی مثال کے متغیرات۔

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

کلاس کا سائز

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

اشیاء

انکیپسولیشن

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

ڈیمیٹر کا قانون

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

• خود کار آبجیکٹ کے طریقے (دوسرے الفاظ میں، "یہ" آبجیکٹ)؛
• حرکت کے طریقہ کار کے اندر تخلیق کردہ اشیاء کے طریقے ؛
• دلائل کے طور پر منظور شدہ اشیاء کے طریقے ( arg1 , arg2 )؛
• اندرونی کار اشیاء کے طریقے (دوبارہ، "یہ")۔

دوسرے لفظوں میں، ڈیمیٹر کا قانون کچھ ایسا ہی ہے جو والدین کسی بچے سے کہہ سکتے ہیں: "آپ اپنے دوستوں سے بات کر سکتے ہیں، لیکن اجنبیوں سے نہیں"۔

ڈیٹا کا ڈھانچہ

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

@Setter
@Getter
@NoArgsConstructor
public class UserDto {
    private long id;
    private String firstName;
    private String lastName;
    private String email;
    private String password;
}

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

متغیرات کی تخلیق کے اصول

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

1. مثالی طور پر، آپ کو کسی متغیر کو استعمال کرنے سے پہلے اس کا اعلان اور آغاز کرنا چاہیے (ایک مت بنائیں اور اسے بھول جائیں)۔
2. جب بھی ممکن ہو، متغیرات کو حتمی قرار دیں تاکہ ان کی قدر کو ابتدا کے بعد تبدیل ہونے سے روکا جا سکے۔
3. کاؤنٹر متغیر کے بارے میں مت بھولنا، جو ہم عام طور پر کسی نہ کسی قسم کے لوپ میں استعمال کرتے ہیں ۔ یعنی، انہیں صفر کرنا نہ بھولیں۔ ورنہ ہماری ساری منطق ٹوٹ سکتی ہے۔
4. آپ کو کنسٹرکٹر میں متغیرات کو شروع کرنے کی کوشش کرنی چاہئے۔
5. اگر کسی آبجیکٹ کو حوالہ کے ساتھ یا بغیر ( new SomeObject() ) کے استعمال کے درمیان کوئی انتخاب ہے تو اس کے بغیر انتخاب کریں، کیونکہ آبجیکٹ کے استعمال ہونے کے بعد اسے اگلے کوڑا کرکٹ جمع کرنے کے چکر میں حذف کر دیا جائے گا اور اس کے وسائل ضائع نہیں ہوں گے۔
6. متغیر کی زندگی بھر (متغیر کی تخلیق اور آخری بار اس کا حوالہ دینے کے درمیان فاصلہ) جتنا ممکن ہو کم رکھیں۔
7. لوپ میں استعمال ہونے والے متغیرات کو لوپ سے بالکل پہلے شروع کریں، نہ کہ اس طریقہ کے آغاز میں جس میں لوپ شامل ہو۔
8. ہمیشہ انتہائی محدود دائرہ کار کے ساتھ شروع کریں اور صرف ضروری ہونے پر پھیلائیں (آپ کو ایک متغیر کو زیادہ سے زیادہ مقامی بنانے کی کوشش کرنی چاہئے)۔
9. ہر متغیر کو صرف ایک مقصد کے لیے استعمال کریں۔
10. پوشیدہ مقصد کے ساتھ متغیرات سے بچیں، مثلاً دو کاموں کے درمیان متغیر کی تقسیم — اس کا مطلب ہے کہ اس کی قسم ان میں سے کسی ایک کو حل کرنے کے لیے موزوں نہیں ہے۔

طریقے

فلم "اسٹار وار: قسط III - سیتھ کا بدلہ" (2005) سے

آئیے براہ راست اپنی منطق کے نفاذ کی طرف چلتے ہیں، یعنی طریقوں کی طرف۔

1. اصول نمبر 1 - کومپیکٹنس۔ مثالی طور پر، ایک طریقہ 20 لائنوں سے زیادہ نہیں ہونا چاہیے۔ اس کا مطلب یہ ہے کہ اگر کوئی عوامی طریقہ نمایاں طور پر "سوجن" ہے، تو آپ کو منطق کو الگ کرنے اور اسے الگ نجی طریقوں میں منتقل کرنے کے بارے میں سوچنے کی ضرورت ہے۔

2. قاعدہ نمبر 2 — if , else , while اور دیگر بیانات میں بہت زیادہ نیسٹڈ بلاکس نہیں ہونے چاہئیں: بہت ساری نیسٹنگ کوڈ کی پڑھنے کی اہلیت کو نمایاں طور پر کم کرتی ہے۔ مثالی طور پر، آپ کے پاس دو سے زیادہ نیسٹڈ {} بلاکس نہیں ہونے چاہئیں۔

   اور ان بلاکس میں کوڈ کو کمپیکٹ اور سادہ رکھنا بھی ضروری ہے۔

3. قاعدہ نمبر 3 - ایک طریقہ کو صرف ایک آپریشن کرنا چاہئے۔ یعنی، اگر کوئی طریقہ ہر طرح کی پیچیدہ منطق انجام دیتا ہے، تو ہم اسے ذیلی طریقوں میں توڑ دیتے ہیں۔ نتیجے کے طور پر، طریقہ خود ایک اگواڑا ہوگا جس کا مقصد دیگر تمام کارروائیوں کو درست ترتیب میں کال کرنا ہے۔

   لیکن کیا ہوگا اگر آپریشن کو الگ طریقہ میں ڈالنے کے لئے بہت آسان لگتا ہے؟ یہ سچ ہے کہ بعض اوقات چڑیوں پر توپ چلانے کی طرح محسوس ہوتا ہے، لیکن چھوٹے طریقے بہت سے فوائد فراہم کرتے ہیں:

   • بہتر کوڈ کی سمجھ؛
   • ترقی کے ساتھ ساتھ طریقے مزید پیچیدہ ہوتے جاتے ہیں۔ اگر کوئی طریقہ شروع کرنا آسان ہے، تو اس کی فعالیت کو پیچیدہ کرنا قدرے آسان ہو جائے گا۔
   • نفاذ کی تفصیلات پوشیدہ ہیں؛
   • آسان کوڈ دوبارہ استعمال؛
   • زیادہ قابل اعتماد کوڈ۔

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

5. طریقہ کے دلائل - مثالی نمبر کیا ہے؟ مثالی طور پر، کوئی بھی نہیں :) لیکن کیا واقعی ایسا ہوتا ہے؟ اس نے کہا، آپ کو زیادہ سے زیادہ کم دلائل رکھنے کی کوشش کرنی چاہئے، کیونکہ جتنے کم ہیں، طریقہ استعمال کرنا اتنا ہی آسان ہے اور اسے جانچنا اتنا ہی آسان ہے۔ شک ہونے پر، ان پٹ پیرامیٹرز کی ایک بڑی تعداد کے ساتھ طریقہ استعمال کرنے کے لیے تمام منظرناموں کا اندازہ لگانے کی کوشش کریں۔

6. مزید برآں، ان طریقوں کو الگ کرنا اچھا ہوگا جن میں بولین فلیگ ان پٹ پیرامیٹر کے طور پر ہوتا ہے، کیونکہ یہ سب بذات خود یہ ظاہر کرتا ہے کہ طریقہ ایک سے زیادہ آپریشن کرتا ہے (اگر سچ ہے، تو ایک کام کریں؛ اگر غلط، تو دوسرا کریں)۔ جیسا کہ میں نے اوپر لکھا ہے، یہ اچھا نہیں ہے اور اگر ممکن ہو تو اس سے بچنا چاہیے۔

7. اگر کسی طریقہ میں ان پٹ پیرامیٹرز کی ایک بڑی تعداد ہے (ایک انتہائی 7 ہے، لیکن آپ کو واقعی 2-3 کے بعد سوچنا شروع کر دینا چاہیے)، تو کچھ دلائل کو الگ آبجیکٹ میں گروپ کیا جانا چاہیے۔

8. اگر بہت سے ملتے جلتے (اوور لوڈڈ) طریقے ہیں، تو ایک جیسے پیرامیٹرز کو اسی ترتیب میں پاس کیا جانا چاہیے: یہ پڑھنے کی اہلیت اور استعمال کو بہتر بناتا ہے۔

9. جب آپ پیرامیٹرز کو کسی طریقہ پر منتقل کرتے ہیں، تو آپ کو یقین ہونا چاہیے کہ وہ سب استعمال کیے گئے ہیں، ورنہ آپ کو ان کی ضرورت کیوں ہے؟ کسی بھی غیر استعمال شدہ پیرامیٹرز کو انٹرفیس سے کاٹ دیں اور اس کے ساتھ کیا جائے۔

10. کوشش/کیچ فطرت میں بہت اچھا نہیں لگتا، لہذا اسے ایک الگ انٹرمیڈیٹ طریقہ (استثنیات سے نمٹنے کا طریقہ) میں منتقل کرنا اچھا خیال ہوگا:

    public void exceptionHandling(SomeObject obj) {
        try {
            someMethod(obj);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

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