ڪوڊنگ جا ضابطا: سسٽم ٺاهڻ کان وٺي شيون ڪم ڪرڻ تائين

سٺو ڏينهن، هرڪو! اڄ اسان توهان سان سٺي ڪوڊ لکڻ بابت ڳالهائڻ چاهيون ٿا. يقينن، هرڪو اهو نه چاهيندو آهي ته ڪتابن وانگر صاف ڪوڊ صحيح طور تي چيل، ڇاڪاڻ ته انهن ۾ معلومات جي وڏي مقدار تي مشتمل آهي پر پهرين ۾ گهڻو واضح ناهي. ۽ وقت سان توهان پڙهڻ ختم ڪري سگهو ٿا، توهان شايد پنهنجي سڀني خواهش کي ڪوڊ ڪرڻ جي خواهش کي ماريو. انهن سڀني تي غور ڪندي، اڄ مان توهان کي مهيا ڪرڻ چاهيان ٿو هڪ ننڍڙو گائيڊ (سفارش جو هڪ ننڍڙو سيٽ) بهتر ڪوڊ لکڻ لاءِ. هن آرٽيڪل ۾، اچو ته هڪ سسٽم ٺاهڻ ۽ انٽرفيس، طبقن ۽ شين سان ڪم ڪرڻ سان لاڳاپيل بنيادي قاعدن ۽ تصورن تي وڃو. هن آرٽيڪل کي پڙهڻ ۾ گهڻو وقت نه لڳندو ۽، اميد اٿم، توهان کي بور نه ڪندو. مان پنھنجي طريقي سان ڪم ڪندس چوٽي کان ھيٺ تائين، يعني ايپليڪيشن جي عام ڍانچي کان ان جي تنگ تفصيل تائين.

سسٽم

ھيٺيون آھن عام طور تي ھڪڙي سسٽم جون خاصيتون آھن:

• گھٽ ۾ گھٽ پيچيدگي. تمام گهڻو پيچيده منصوبن کان بچڻ گهرجي. سڀ کان اهم شيء سادگي ۽ وضاحت آهي (سادگي = بهتر).
• سار سنڀال جي آسانيء. جڏهن ايپليڪيشن ٺاهي، توهان کي ياد رکڻ گهرجي ته ان کي برقرار رکڻ جي ضرورت پوندي (جيتوڻيڪ توهان ذاتي طور تي ان کي برقرار رکڻ لاء ذميوار نه هوندا). هن جو مطلب آهي ته ڪوڊ واضح ۽ واضح هجڻ گهرجي.
• لوز جوڙڻ. هن جو مطلب اهو آهي ته اسان پروگرام جي مختلف حصن جي وچ ۾ انحصار جو تعداد گھٽائي ٿو (او پي جي اصولن سان اسان جي تعميل کي وڌايو).
• ٻيهر استعمال ڪرڻ جي صلاحيت. اسان پنھنجي سسٽم کي ٻين ايپليڪيشنن ۾ اجزاء کي ٻيهر استعمال ڪرڻ جي صلاحيت سان ٺاھيو آھي.
• پورٽبلٽي. اهو آسان هجڻ گهرجي ته هڪ سسٽم کي ٻئي ماحول سان ترتيب ڏيڻ لاء.
• يونيفارم انداز. اسان پنھنجي سسٽم کي ان جي مختلف حصن ۾ يونيفارم انداز استعمال ڪندي ٺاھيو آھي.
• توسيع (اسڪاليبلٽي). اسان سسٽم کي ان جي بنيادي ڍانچي جي ڀڃڪڙي ڪرڻ کان سواء وڌائي سگھون ٿا (جزيو شامل ڪرڻ يا تبديل ڪرڻ ٻين سڀني کي متاثر نه ڪرڻ گهرجي).

اهو عملي طور تي ناممڪن آهي هڪ ايپليڪيشن ٺاهڻ لاء جيڪو ترميمن يا نئين ڪارڪردگي جي ضرورت ناهي. اسان کي مسلسل نوان حصا شامل ڪرڻ جي ضرورت پوندي ته جيئن اسان جي دماغي ٻار کي وقت سان گڏ رهڻ ۾ مدد ملي. هي اهو آهي جتي اسڪاليبلٽي راند ۾ اچي ٿي. اسڪالبلٽي بنيادي طور تي ايپليڪيشن کي وڌائڻ، نئين ڪارڪردگي شامل ڪرڻ، ۽ وڌيڪ وسيلن سان ڪم ڪرڻ (يا، ٻين لفظن ۾، وڏي لوڊ سان). ٻين لفظن ۾، نئين منطق شامل ڪرڻ کي آسان بڻائڻ لاءِ، اسان ڪجھ قاعدن تي قائم رھون ٿا، جھڙوڪ ماڊولرٽي وڌائڻ سان سسٽم جي جوڙيل کي گھٽائڻ.

تصوير جو ذريعو

سسٽم جي جوڙجڪ جا مرحلا

1. سافٽ ويئر سسٽم. مجموعي طور تي ايپليڪيشن کي ترتيب ڏيو.
2. ذيلي سسٽم / پيڪيجز ۾ تقسيم. منطقي طور تي الڳ حصن جي وضاحت ڪريو ۽ انهن جي وچ ۾ رابطي لاء قاعدن جي وضاحت ڪريو.
3. طبقن ۾ ذيلي سسٽم جي تقسيم. سسٽم جي حصن کي مخصوص طبقن ۽ انٽرفيس ۾ ورهايو، ۽ انهن جي وچ ۾ رابطي جي وضاحت ڪريو.
4. طريقن ۾ طبقن جي تقسيم. ھڪڙي طبقي لاءِ ضروري طريقن جي مڪمل تعريف ٺاھيو، ان جي مقرر ڪيل ذميواري جي بنياد تي.
5. ٺاھڻ جو طريقو. انفرادي طريقن جي ڪارڪردگي جي تفصيلي تعريف ٺاهيو.

عام طور تي عام ڊولپرز هن ڊزائن کي سنڀاليندا آهن، جڏهن ته ايپليڪيشن جو معمار مٿي بيان ڪيل پوائنٽس کي سنڀاليندو آهي.

سسٽم جي جوڙجڪ جا عام اصول ۽ تصور

سست شروعات. هن پروگرامنگ محاوري ۾، ايپليڪيشن ڪنهن شئي کي ٺاهڻ ۾ وقت ضايع نٿو ڪري جيستائين اهو اصل ۾ استعمال نه ڪيو وڃي. هي شروعاتي عمل کي تيز ڪري ٿو ۽ گندگي ڪليڪٽر تي لوڊ گھٽائي ٿو. اهو چيو ته، توهان کي اهو تمام گهڻو پري نه وٺڻ گهرجي، ڇاڪاڻ ته اهو ماڊليت جي اصول جي ڀڃڪڙي ڪري سگهي ٿو. ٿي سگهي ٿو ته اهو ضروري آهي ته تعمير جي سڀني مثالن کي ڪجهه خاص حصي ڏانهن منتقل ڪيو وڃي، مثال طور، مکيه طريقو يا ڪارخاني جي طبقي ڏانهن. سٺي ڪوڊ جي ھڪڙي خصوصيت بار بار، بوائلر پليٽ ڪوڊ جي غير موجودگي آھي. ضابطي جي طور تي، اهڙي ڪوڊ هڪ الڳ ڪلاس ۾ رکيل آهي ته جيئن ضرورت هجي ته ان کي سڏي سگهجي.

AOP

مان پڻ نوٽ ڪرڻ چاهيان ٿو پہلو تي مبني پروگرامنگ. هي پروگرامنگ پيراڊم تمام شفاف منطق کي متعارف ڪرائڻ بابت آهي. اهو آهي، ورجائيندڙ ڪوڊ کي طبقن ۾ رکيو ويندو آهي (پنهنجو) ۽ سڏيو ويندو آهي جڏهن ڪجهه شرطون مطمئن آهن. مثال طور، جڏهن هڪ مخصوص نالي سان هڪ طريقو سڏين ٿا يا هڪ مخصوص قسم جي متغير تائين رسائي. ڪڏهن ڪڏهن پهلو مونجهارو ٿي سگهي ٿو، ڇاڪاڻ ته اهو فوري طور تي واضح ناهي ته ڪوڊ ڪٿان سڏيو وڃي ٿو، پر اهو اڃا تائين تمام مفيد ڪارڪردگي آهي. خاص طور تي جڏهن ڪيشنگ يا لاگنگ. اسان عام طبقن ۾ اضافي منطق شامل ڪرڻ کان سواء هن ڪارڪردگي کي شامل ڪندا آهيون. ڪينٽ بيڪ جا چار قاعدا هڪ سادي فن تعمير لاءِ:

1. اظهار - هڪ طبقي جو ارادو واضح طور تي ظاهر ڪيو وڃي. اهو مناسب نالو ڏيڻ، ننڍڙي سائيز، ۽ اڪيلو ذميواري اصول جي پيروي ڪرڻ ذريعي حاصل ڪيو ويو آهي (جنهن تي اسان هيٺ وڌيڪ تفصيل سان غور ڪنداسين).
2. طبقن ۽ طريقن جو گھٽ ۾ گھٽ تعداد - توھان جي خواهش ۾ ڪلاسز کي جيترو ٿي سگھي ننڍو ۽ تنگ ڪيو وڃي، توھان تمام گھڻو پري وڃي سگھو ٿا (نتيجي ۾ شاٽ گن سرجري مخالف نمونو). اهو اصول سسٽم کي ٺهڪندڙ رکڻ ۽ تمام گهڻو پري نه وڃڻ، هر ممڪن عمل لاءِ هڪ الڳ ڪلاس ٺاهڻ جو مطالبو ڪري ٿو.
3. ڪو به نقل نه - نقلي ڪوڊ، جيڪو مونجهارو پيدا ڪري ٿو ۽ ذيلي اپٽيمل سسٽم ڊيزائن جو اشارو آهي، ڪڍيو ويو آهي ۽ هڪ الڳ هنڌ ڏانهن منتقل ڪيو ويو آهي.
4. سڀني ٽيسٽن کي ھلائي ٿو - ھڪڙو سسٽم جيڪو سڀني ٽيسٽ پاس ڪري ٿو انتظام قابل آھي. ڪا به تبديلي امتحان جي ناڪامي جو سبب بڻجي سگهي ٿي، اسان کي ظاهر ڪري ٿي ته هڪ طريقي جي اندروني منطق ۾ اسان جي تبديلي پڻ غير متوقع طريقن سان سسٽم جي رويي کي تبديل ڪيو.

سولڊ

جڏهن هڪ سسٽم کي ڊزائين ڪرڻ، معروف SOLID اصولن تي غور ڪرڻ جي قابل آهن:

S (اڪيلو ذميواري)، اي (کليل-بند)، ايل (ليسڪوف متبادل)، آء (انٽرفيس سيگريشن)، ڊي (انحصار جي ڦيرڦار).

اسان هر فرد جي اصول تي نه رهنداسين. اهو هن مضمون جي دائري کان ٿورو ٻاهر هوندو، پر توهان هتي وڌيڪ پڙهي سگهو ٿا .

انٽرفيس

شايد چڱي طرح ٺهيل ڪلاس ٺاهڻ ۾ سڀ کان اهم قدمن مان هڪ هڪ سٺو ڊزائين ڪيل انٽرفيس ٺاهي رهيو آهي جيڪو سٺو تجزيه جي نمائندگي ڪري ٿو، طبقي جي عمل درآمد جي تفصيل کي لڪائي ٿو ۽ گڏوگڏ طريقن جو هڪ گروپ پيش ڪري ٿو جيڪو واضح طور تي هڪ ٻئي سان مطابقت رکي ٿو. اچو ته هڪ ويجهي نظر رکون SOLID اصولن مان هڪ تي - انٽرفيس سيگريگيشن: ڪلائنٽ (ڪلاس) کي غير ضروري طريقن تي عمل نه ڪرڻ گهرجي جيڪي اهي استعمال نه ڪندا. ٻين لفظن ۾، جيڪڏهن اسان گهٽ ۾ گهٽ طريقن سان هڪ انٽرفيس ٺاهڻ جي باري ۾ ڳالهائي رهيا آهيون جنهن جو مقصد صرف انٽرفيس جي ڪم کي انجام ڏيڻ آهي (جيڪو مان سمجهان ٿو ته اڪيلو ذميواري اصول سان تمام گهڻو ملندو آهي)، اهو بهتر آهي ته ان جي بدران ٻه ننڍا ٺاهي. هڪ bloated انٽرفيس جي. خوشقسمتيء سان، هڪ طبقو هڪ کان وڌيڪ انٽرفيس لاڳو ڪري سگهي ٿو. ياد رکو ته توهان جي انٽرفيس کي صحيح طرح سان نالو ڏيو: نالو لازمي طور تي مقرر ڪيل ڪم کي ممڪن طور تي ظاهر ڪرڻ گهرجي. ۽، يقينا، اهو ننڍڙو آهي، گهٽ مونجهارو اهو ٿيندو. دستاويزي تبصرا عام طور تي انٽرفيس سطح تي لکيل آهن. اهي تبصرا تفصيل فراهم ڪن ٿا ته هر طريقي کي ڇا ڪرڻ گهرجي، ڪهڙو دليل اهو وٺندو آهي، ۽ اهو ڇا موٽندو.

ڪلاس

تصوير جو ذريعو

اچو ته هڪ نظر رکون ته ڪيئن ڪلاس اندروني طور تي ترتيب ڏنل آهن. يا بلڪه، ڪجهه نقطه نظر ۽ ضابطا جيڪي ڪلاس لکڻ دوران پيروي ڪرڻ گهرجن. ضابطي جي طور تي، هڪ طبقي کي هڪ مخصوص ترتيب ۾ متغير جي فهرست سان شروع ڪرڻ گهرجي:

1. عوامي جامد مستقل؛
2. نجي جامد مستقل؛
3. نجي مثال متغير.

ان کان پوءِ مختلف ٺاھڻ وارا اچن ٿا، انھن لاءِ جيڪي ٿورڙي دليلن سان گڏ آھن انھن کان وٺي سڀ کان وڌيڪ. انهن طريقن جي پيروي ڪئي وئي آهي سڀ کان وڌيڪ عوامي کان سڀ کان وڌيڪ نجي تائين. عام طور تي ڳالهائڻ، پرائيويٽ طريقا جيڪي ڪجهه ڪارڪردگي جي عمل کي لڪائيندا آهن جن کي اسين محدود ڪرڻ چاهيون ٿا، تمام تري ۾ آهن.

ڪلاس جي ماپ

هاڻي مان ڪلاسن جي سائيز بابت ڳالهائڻ چاهيندس. اچو ته SOLID اصولن مان هڪ کي ياد ڪريون - واحد ذميواري اصول. اهو ٻڌائي ٿو ته هر شئي جو صرف هڪ مقصد (ذميداري) آهي، ۽ ان جي سڀني طريقن جي منطق جو مقصد ان کي پورو ڪرڻ آهي. اهو اسان کي ٻڌائي ٿو ته وڏن، ڦاٿل طبقن کان پاسو ڪرڻ لاءِ (جيڪي اصل ۾ خدا جو اعتراض مخالف نمونو آهن) ۽ جيڪڏهن اسان وٽ ڪيترائي طريقا آهن جن سان مختلف قسم جي منطقن کي هڪ طبقي ۾ جڙيل آهي، اسان کي ان کي ٽوڙڻ بابت سوچڻ گهرجي. منطقي حصن جا ٻه (ڪلاس). اهو، موڙ ۾، ڪوڊ جي پڙهڻ جي صلاحيت وڌائيندو، ڇاڪاڻ ته اهو هر طريقي جي مقصد کي سمجهڻ ۾ گهڻو وقت نه وٺندو جيڪڏهن اسان ڄاڻون ٿا ته ڪنهن به ڏنل طبقي جي تقريبن مقصد. انهي سان گڏ، ڪلاس جي نالي تي نظر رکو، جنهن کي ان ۾ شامل منطق کي ظاهر ڪرڻ گهرجي. مثال طور، جيڪڏهن اسان وٽ هڪ ڪلاس آهي جنهن جي نالي ۾ 20+ لفظ آهن، اسان کي سوچڻ جي ضرورت آهي ريفيڪٽرنگ بابت. ڪنهن به خود اعتمادي واري طبقي ۾ ايتريون اندروني تبديليون نه هجڻ گهرجن. حقيقت ۾، هر طريقو انهن مان هڪ يا ڪجهه سان ڪم ڪري ٿو، جنهن ڪري طبقي جي اندر تمام گهڻي هم آهنگي پيدا ٿئي ٿي (جيڪو بلڪل ائين ئي هجڻ گهرجي، ڇو ته طبقو هڪ گڏيل سڄو هجڻ گهرجي). نتيجي طور، هڪ طبقي جي هڪجهڙائي وڌائڻ سان طبقي جي سائيز ۾ گهٽتائي ٿئي ٿي، ۽ يقينا، طبقن جو تعداد وڌي ٿو. اهو ڪجهه ماڻهن لاءِ پريشان ڪندڙ آهي، ڇو ته توهان کي ڪلاس فائلن جي چوڌاري وڌيڪ استعمال ڪرڻ جي ضرورت آهي انهي کي ڏسڻ لاءِ ته هڪ مخصوص وڏو ڪم ڪيئن ڪم ڪري ٿو. سڀ کان وڌيڪ، هر ڪلاس هڪ ننڍڙو ماڊل آهي جيڪو گهٽ ۾ گهٽ ٻين سان لاڳاپيل هجڻ گهرجي. هي اڪيلائي انهن تبديلين جو تعداد گھٽائي ٿي جيڪا اسان کي ٺاهڻ جي ضرورت آهي جڏهن ڪلاس ۾ اضافي منطق شامل ڪيو وڃي.

شيون

انڪپسوليشن

هتي اسان پهرين OOP اصول بابت ڳالهائينداسين: encapsulation. عملدرآمد کي لڪائڻ جو مطلب نه آهي ته متغيرن کي موڙيندڙ طريقي سان ٺاهيو وڃي (سوچڻ سان انفرادي طريقن، حاصل ڪندڙن ۽ سيٽرن ذريعي رسائي کي محدود ڪرڻ، جيڪو سٺو ناهي، ڇو ته انڪپسوليشن جو سڄو نقطو گم ٿي ويو آهي). لڪائڻ جي رسائي جو مقصد خلاصو ٺاهڻ جو مقصد آهي، اهو آهي، ڪلاس حصيداري ڪنڪريٽ طريقا مهيا ڪري ٿو جيڪي اسان اسان جي ڊيٽا سان ڪم ڪرڻ لاء استعمال ڪندا آهيون. ۽ صارف کي اهو ڄاڻڻ جي ضرورت ناهي ته اسان هن ڊيٽا سان ڪيئن ڪم ڪري رهيا آهيون - اهو ڪم ڪري ٿو ۽ اهو ڪافي آهي.

Demeter جو قانون

اسان Demeter جي قانون تي پڻ غور ڪري سگھون ٿا: اهو ضابطن جو هڪ ننڍڙو سيٽ آهي جيڪو طبقي ۽ طريقي جي سطح تي پيچيدگي کي منظم ڪرڻ ۾ مدد ڪري ٿو. فرض ڪريو اسان وٽ ڪار آبجیکٹ آهي، ۽ ان ۾ هڪ حرڪت آهي (Object arg1، Object arg2) طريقو. Demeter جي قانون موجب، هي طريقو سڏڻ تائين محدود آهي:

• خود ڪار اعتراض جا طريقا (ٻين لفظن ۾، "هي" اعتراض)؛
• حرڪت واري طريقي ۾ ٺاهيل شيون جا طريقا ؛
• اعتراضن جي طور تي منظور ڪيل شيون جا طريقا ( arg1 ، arg2 )؛
• اندروني ڪار جي شين جا طريقا (ٻيهر، "هي").

ٻين لفظن ۾، ڊيميٽر جو قانون اهو آهي ته ڇا والدين ٻار کي چوندا آهن: "توهان پنهنجي دوستن سان ڳالهائي سگهو ٿا، پر اجنبي سان نه".

ڊيٽا جي جوڙجڪ

ڊيٽا جي جوڙجڪ سان لاڳاپيل عناصر جو هڪ مجموعو آهي. جڏهن هڪ اعتراض کي ڊيٽا جي جوڙجڪ جي طور تي غور ڪيو وڃي، اتي ڊيٽا عناصر جو هڪ سيٽ آهي جنهن تي طريقا هلندا آهن. انهن طريقن جو وجود واضح طور تي فرض ڪيو ويو آهي. اهو آهي، هڪ ڊيٽا جي جوڙجڪ هڪ اعتراض آهي جنهن جو مقصد ذخيرو ٿيل ڊيٽا کي (پروسيس) سان گڏ ڪم ڪرڻ ۽ ڪم ڪرڻ آهي. باقاعده اعتراض کان ان جو اهم فرق اهو آهي ته هڪ عام اعتراض طريقن جو هڪ مجموعو آهي جيڪو ڊيٽا عناصر تي ڪم ڪري ٿو جيڪي واضح طور تي موجود آهن. ڇا توهان سمجهو ٿا؟ هڪ عام شئي جو بنيادي پاسو طريقو آهي. اندروني متغير انهن جي صحيح آپريشن کي آسان بڻائي ٿو. پر ڊيٽا جي جوڙجڪ ۾، طريقا موجود آهن توهان جي ڪم کي ذخيرو ٿيل ڊيٽا عناصر سان مدد ڏيڻ لاء، جيڪي هتي اهم آهن. ڊيٽا جي جوڙجڪ جو هڪ قسم هڪ ڊيٽا جي منتقلي اعتراض (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. counter variables جي باري ۾ نه وساريو، جنهن کي اسين عام طور تي ڪنهن قسم جي لوپ ۾ استعمال ڪندا آهيون . اهو آهي، انهن کي صفر ڪرڻ نه وساريو. ٻي صورت ۾، اسان جا سڀئي منطق ڀڄي سگهن ٿا.
4. توھان کي ڪوشش ڪرڻ گھرجي ته ٺاھيندڙ ۾ متغيرن کي شروع ڪريو.
5. جيڪڏهن ڪنهن شئي کي حوالي سان استعمال ڪرڻ جي وچ ۾ يا ( new SomeObject() ) جي وچ ۾ ڪو اختيار آهي، ان کان سواءِ چونڊيو، ڇاڪاڻ ته اعتراض استعمال ٿيڻ کان پوءِ ان کي ختم ڪيو ويندو ايندڙ ڪچري کي گڏ ڪرڻ واري چڪر دوران ۽ ان جا وسيلا ضايع نه ٿيندا.
6. متغير جي زندگي گذارڻ (متغير جي تخليق ۽ آخري وقت جي وچ ۾ فاصلو) جيترو ٿي سگھي مختصر رکو.
7. لوپ ۾ استعمال ٿيندڙ متغيرن کي شروع ڪريو صرف لوپ کان اڳ، نه ان طريقي جي شروعات ۾ جنهن ۾ لوپ شامل آهي.
8. هميشه سڀ کان وڌيڪ محدود دائري سان شروع ڪريو ۽ صرف ان وقت وڌايو جڏهن ضروري هجي (توهان کي ڪوشش ڪرڻ گهرجي ته ممڪن طور تي مقامي طور تي متغير ٺاهڻ).
9. هر متغير کي صرف هڪ مقصد لاءِ استعمال ڪريو.
10. لڪيل مقصد سان متغيرن کان پاسو ڪريو، مثال طور ٻن ڪمن جي وچ ۾ متغير ورهائڻ - ان جو مطلب آهي ته ان جو قسم انهن مان هڪ کي حل ڪرڻ لاءِ مناسب ناهي.

طريقا

فلم مان "اسٽار وار: قسط III - سيٿ جو بدلو" (2005)

اچو ته سڌو سنئون اسان جي منطق تي عمل ڪرڻ لاء، يعني طريقن ڏانهن.

1. ضابطو # 1 - مطابقت. مثالي طور، هڪ طريقو 20 لائنن کان وڌيڪ نه هجڻ گهرجي. هن جو مطلب اهو آهي ته جيڪڏهن هڪ عوامي طريقو خاص طور تي "سويل" آهي، توهان کي منطق کي ٽوڙڻ ۽ الڳ الڳ نجي طريقن ۾ منتقل ڪرڻ بابت سوچڻ جي ضرورت آهي.

2. ضابطو # 2 - if , else , while ۽ ٻين بيانن ۾ نه هئڻ گهرجي تمام گھڻا nested بلاڪ: گھڻا nesting خاص طور تي ڪوڊ جي پڙهڻ جي صلاحيت کي گھٽائي ٿو. مثالي طور، توھان کي ٻن کان وڌيڪ نسٽڊ {} بلاڪ نه ھجڻ گھرجي.

   ۽ اهو پڻ ضروري آهي ته ڪوڊ کي انهن بلاڪن ۾ ٺهيل ۽ سادو رکڻ لاء.

3. ضابطو #3 - هڪ طريقو صرف هڪ آپريشن ڪرڻ گهرجي. اهو آهي، جيڪڏهن هڪ طريقو سڀني قسمن جي پيچيده منطق کي انجام ڏئي ٿو، اسان ان کي ذيلي طريقن ۾ ٽوڙيو ٿا. نتيجي طور، طريقو پاڻ هڪ منهن هوندو جنهن جو مقصد ٻين سڀني عملن کي صحيح ترتيب ۾ سڏڻ آهي.

   پر ڇا جيڪڏهن آپريشن تمام سادو لڳي ٿو ته هڪ الڳ طريقو ۾ رکڻ لاء؟ سچ پچ، ڪڏهن ڪڏهن اهو محسوس ڪري سگھي ٿو ته ڦڦڙن تي توپ فائر ڪرڻ وانگر، پر ننڍا طريقا ڪيترائي فائدا مهيا ڪن ٿا:

   • بهتر ڪوڊ فهم؛
   • طريقا وڌيڪ پيچيده ٿي ويندا آهن جيئن ترقي جي ترقي. جيڪڏهن هڪ طريقو سادو آهي شروع ڪرڻ سان، پوء ان جي ڪارڪردگي کي پيچيده ڪرڻ لاء ٿورو آسان ٿيندو.
   • لاڳو ڪرڻ جا تفصيل لڪيل آهن؛
   • آسان ڪوڊ ٻيهر استعمال؛
   • وڌيڪ قابل اعتماد ڪوڊ.

4. اسٽيپ ڊائون قاعدو - ڪوڊ کي مٿي کان هيٺ تائين پڙهڻ گهرجي: توهان جيترو هيٺ پڙهو ٿا، اوترو ئي اوترو توهان منطق ۾ وڌو ٿا. ۽ ان جي برعڪس، توهان مٿي وڃو، وڌيڪ تجريدي طريقا. مثال طور، switch بيان نه بلڪه نان-ڪمپيٽ ۽ ناپسنديده آهن، پر جيڪڏهن توهان سوئچ استعمال ڪرڻ کان پاسو نٿا ڪري سگهو، توهان کي ڪوشش ڪرڻ گهرجي ته ان کي جيترو ٿي سگهي گهٽ، هيٺين سطح جي طريقن ڏانهن.

5. طريقو دليل - مثالي نمبر ڇا آهي؟ مثالي طور تي، ڪو به نه :) پر ڇا اهو واقعي ٿئي ٿو؟ اهو چيو ته، توهان کي ممڪن طور تي گهٽ دليل ڏيڻ جي ڪوشش ڪرڻ گهرجي، ڇاڪاڻ ته گهٽ آهن، اهو طريقو استعمال ڪرڻ آسان آهي ۽ ان کي جانچڻ آسان آهي. جڏهن شڪ ۾، وڏي تعداد ۾ ان پٽ پيٽرولر سان طريقو استعمال ڪرڻ لاء سڀني منظرنامن کي پيش ڪرڻ جي ڪوشش ڪريو.

6. اضافي طور تي، اھو بھتر ٿيندو ته انھن طريقن کي الڳ ڪيو وڃي جن وٽ ھڪڙو ان پٽ پيراميٽر آھي، ڇاڪاڻ ته اھو سڀ ڪجھ پاڻ ۾ مطلب آھي ته طريقو ھڪڙي کان وڌيڪ آپريشن انجام ڏئي ٿو (جيڪڏھن صحيح آھي، پوء ھڪڙي ڪم ڪريو؛ جيڪڏھن غلط آھي، پوء ٻيو ڪريو). جيئن مون مٿي لکيو آهي، اهو سٺو ناهي ۽ جيڪڏهن ممڪن هجي ته بچڻ گهرجي.

7. جيڪڏهن هڪ طريقي ۾ وڏي تعداد ۾ ان پٽ پيٽرولر آهن (هڪ انتهائي 7 آهي، پر توهان کي واقعي 2-3 کان پوء سوچڻ شروع ڪرڻ گهرجي)، ڪجهه دليلن کي هڪ الڳ اعتراض ۾ گروپ ڪيو وڃي.

8. جيڪڏهن اهڙا ڪيترائي ساڳيا (اوور لوڊ ٿيل) طريقا آهن، ته پوءِ ساڳيا پيرا ميٽرز کي ساڳئي ترتيب ۾ پاس ڪيو وڃي: هي پڙهڻ جي صلاحيت ۽ استعمال کي بهتر بڻائي ٿو.

9. جڏهن توهان هڪ طريقي سان پيٽرولر پاس ڪندا آهيو، توهان کي پڪ ڪرڻ گهرجي ته اهي سڀئي استعمال ڪيا ويا آهن، ٻي صورت ۾ توهان کي انهن جي ضرورت ڇو آهي؟ انٽرفيس مان ڪنهن به غير استعمال ٿيل پيٽرولن کي ڪٽيو ۽ ان سان ڪيو وڃي.

10. ڪوشش/پڪڙ فطرت ۾ تمام سٺي نظر نه ايندي آهي، تنهنڪري اهو سٺو خيال هوندو ته ان کي هڪ الڳ وچولي طريقي ۾ منتقل ڪيو وڃي (استثناء کي سنڀالڻ جو طريقو):

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

مون مٿي ڏنل نقل واري ڪوڊ بابت ڳالهايو، پر مون کي هڪ ڀيرو ٻيهر ورجائڻ ڏيو: جيڪڏهن اسان وٽ ٻه طريقا آهن بار بار ڪوڊ سان، اسان کي ان کي الڳ طريقي سان منتقل ڪرڻو پوندو. اهو طريقو ۽ ڪلاس ٻنهي کي وڌيڪ ٺهڪندڙ بڻائيندو. انهن ضابطن جي باري ۾ نه وساريو جيڪي نالن کي سنڀاليندا آهن: تفصيلن تي تفصيل سان ڪيئن نالا ڪلاس، انٽرفيس، طريقا، ۽ متغيرن تي مضمون جي ايندڙ حصي ۾ بحث ڪيو ويندو. پر اهو سڀ ڪجهه اڄ مون وٽ آهي.