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

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

سسٽم

سسٽم جي عام گهربل خاصيتون آهن:

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

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

سسٽم جي ڊيزائن جا مرحلا

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

عام طور تي، عام ڊولپرز ڊزائن جا ذميوار آهن، ۽ ايپليڪيشن معمار مٿي بيان ڪيل شيون لاء ذميوار آهي.

سسٽم جي جوڙجڪ جا بنيادي اصول ۽ تصور

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

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

SOLID جڏهن هڪ سسٽم ٺاهيندي، اهو ضروري آهي ته حساب ۾ رکڻ جي سڃاتل اصولن SOLID: S - واحد ذميواري - واحد ذميواري جو اصول؛ او - کليل-بند- کليل/قريب جو اصول؛ L - Liskov متبادل - باربرا Liskov جي متبادل اصول؛ I - انٽرفيس علحدگي - انٽرفيس جي الڳ ٿيڻ جو اصول؛ ڊي - انحصار جي ڦيرڦار - انحصار جي ڦيرڦار جو اصول؛ اسان هر اصول تي خاص طور تي نه رهنداسين (هي هن مضمون جي دائري کان ٿورو ٻاهر آهي، پر توهان وڌيڪ ڳولي سگهو ٿا هتي

انٽرفيس

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

ڪلاس

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

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

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

ڪلاس جي ماپ

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

شيون

انڪپسوليشن

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

Demeter جو قانون

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

• خود اعتراض جا طريقا Car(ٻين لفظن ۾، هي)؛
• ۾ پيدا ڪيل شين جا طريقا move؛
• دليلن جي طور تي منظور ٿيل شيون جا طريقا - arg1, arg2;
• اندروني شين جا طريقا Car(ساڳي ئي هي).

ٻين لفظن ۾، Demeter جو قانون ڪجهه ٻارن جي حڪمراني وانگر آهي - توهان دوستن سان ڳالهائي سگهو ٿا، پر اجنبي سان نه .

ڊيٽا جي جوڙجڪ

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

طريقا

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

1. پهريون اصول compactness آهي. مثالي طور، ھڪڙو طريقو 20 لائنن کان وڌيڪ نه ھجڻ گھرجي، تنھنڪري جيڪڏھن، چوندا آھن، ھڪڙو عوامي طريقو خاص طور تي "سوز" آھي، توھان کي سوچڻ جي ضرورت آھي الڳ ٿيل منطق کي نجي طريقن ۾ منتقل ڪرڻ بابت.

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

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

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

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

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

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();
        }
    }

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