کوڈ لکھنے کے قواعد: نظام بنانے سے لے کر اشیاء کے ساتھ کام کرنے تک

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

سسٹم

نظام کی عمومی مطلوبہ خصوصیات یہ ہیں:

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

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

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

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

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

سسٹم ڈیزائن کے بنیادی اصول اور تصورات

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

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

SOLID کسی نظام کو ڈیزائن کرتے وقت، SOLID کے معروف اصولوں کو مدنظر رکھنا ضروری ہے: S - واحد ذمہ داری - واحد ذمہ داری کا اصول؛ O - کھلا بند - کشادگی/قربت کا اصول؛ L - Liskov متبادل - باربرا Liskov کے متبادل اصول؛ I - انٹرفیس علیحدگی - انٹرفیس علیحدگی کا اصول؛ D - انحصار الٹا - انحصار الٹا اصول؛ ہم ہر اصول پر خاص طور پر غور نہیں کریں گے (یہ اس مضمون کے دائرہ کار سے تھوڑا سا باہر ہے، لیکن آپ یہاں مزید جان سکتے ہیں

انٹرفیس

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

کلاس

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

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

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

کلاس کا سائز

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

اشیاء

انکیپسولیشن

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

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

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

• خود اعتراض کے طریقے Car(دوسرے الفاظ میں، یہ)؛
• میں تخلیق کردہ اشیاء کے moveطریقے
• دلائل کے طور پر منظور شدہ اشیاء کے طریقے - arg1, arg2;
• اندرونی اشیاء کے طریقے Car(یہ وہی)

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

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

ڈیٹا ڈھانچہ متعلقہ عناصر کا مجموعہ ہے۔ جب کسی چیز کو ڈیٹا ڈھانچے کے طور پر غور کیا جاتا ہے، تو یہ ڈیٹا عناصر کا ایک مجموعہ ہوتا ہے جس پر طریقوں سے کارروائی ہوتی ہے، جس کا وجود مضمر طور پر ہوتا ہے۔ یعنی یہ ایک ایسی چیز ہے جس کا مقصد ذخیرہ شدہ ڈیٹا کو ذخیرہ کرنا اور چلانے (عمل) کرنا ہے۔ ریگولر آبجیکٹ سے اہم فرق یہ ہے کہ ایک آبجیکٹ طریقوں کا ایک مجموعہ ہے جو ڈیٹا عناصر پر کام کرتا ہے جن کا وجود مضمر ہے۔ کیا تم سمجھ گئے ہو؟ ایک باقاعدہ آبجیکٹ میں، بنیادی پہلو طریقے ہیں، اور اندرونی متغیرات کا مقصد ان کی درست کارروائی ہے، لیکن ڈیٹا کے ڈھانچے میں یہ اس کے برعکس ہے: طریقے ذخیرہ شدہ عناصر کے ساتھ کام کرنے میں مدد اور مدد کرتے ہیں، جو یہاں اہم ہیں۔ ڈیٹا سٹرکچر کی ایک قسم ڈیٹا ٹرانسفر آبجیکٹ (DTO) ہے ۔ یہ ایک ایسی کلاس ہے جس میں عوامی متغیرات ہیں اور کوئی طریقہ نہیں ہے (یا صرف پڑھنے/لکھنے کے طریقے) جو ڈیٹا بیس کے ساتھ کام کرتے وقت ڈیٹا کو پاس کرتے ہیں، ساکٹ سے پیغامات کو پارس کرنے کے ساتھ کام کرتے ہیں، وغیرہ۔ عام طور پر، ایسی اشیاء میں ڈیٹا زیادہ دیر تک محفوظ نہیں ہوتا ہے تقریباً فوری طور پر اس ہستی میں تبدیل ہو گیا جس کے ساتھ ہماری درخواست کام کرتی ہے۔ ایک ہستی، بدلے میں، ایک ڈیٹا ڈھانچہ بھی ہے، لیکن اس کا مقصد ایپلی کیشن کی مختلف سطحوں پر کاروباری منطق میں حصہ لینا ہے، جبکہ DTO ڈیٹا کو ایپلیکیشن میں/سے منتقل کرنا ہے۔ مثال 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. انسداد متغیرات کے بارے میں مت بھولیں (عام طور پر ہم انہیں کسی نہ کسی طرح کے لوپ میں استعمال کرتے ہیں for، یعنی ہمیں انہیں دوبارہ ترتیب دینا نہیں بھولنا چاہیے، ورنہ یہ ہماری پوری منطق کو توڑ سکتا ہے)۔
4. آپ کو کنسٹرکٹر میں متغیرات کو شروع کرنے کی کوشش کرنی چاہئے۔
5. اگر کسی چیز کو حوالہ کے ساتھ یا اس کے بغیر استعمال کرنے کے درمیان کوئی انتخاب ہو تو ( ) کے بغیرnew SomeObject() انتخاب کریں ، کیونکہ یہ آبجیکٹ، ایک بار استعمال ہونے کے بعد، اگلی کوڑا کرکٹ جمع کرنے کے دوران حذف ہو جائے گا اور وسائل کو ضائع نہیں کرے گا۔
6. متغیرات کی زندگی کو جتنا ممکن ہو چھوٹا بنائیں (متغیر کی تخلیق اور آخری رسائی کے درمیان فاصلہ)۔
7. لوپ میں استعمال ہونے والے متغیرات کو لوپ سے پہلے شروع کریں، نہ کہ لوپ پر مشتمل طریقہ کے آغاز میں۔
8. ہمیشہ انتہائی محدود دائرہ کار کے ساتھ شروع کریں اور صرف ضرورت پڑنے پر ہی اس کو وسعت دیں (آپ کو متغیر کو ممکنہ حد تک مقامی بنانے کی کوشش کرنی چاہیے)۔
9. ہر متغیر کو صرف ایک مقصد کے لیے استعمال کریں۔
10. پوشیدہ معنی والے متغیر سے بچیں (متغیر دو کاموں کے درمیان پھٹا ہوا ہے، جس کا مطلب ہے کہ اس کی قسم ان میں سے کسی ایک کو حل کرنے کے لیے موزوں نہیں ہے)۔

طریقے

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

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

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

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

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

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

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

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

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

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

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

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

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

10. try/catchیہ اپنی نوعیت کے لحاظ سے بہت اچھا نہیں لگتا، لہذا ایک اچھا اقدام یہ ہوگا کہ اسے ایک درمیانی علیحدہ طریقہ (استثنیات سے نمٹنے کا طریقہ) میں منتقل کیا جائے:

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

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