सोप्या आयओएस सॉफ्टवेअर डिझाइनचे चार नियम

१ 1990 1990 ० च्या उत्तरार्धात, एक्सट्रीम प्रोग्रामिंग विकसित करताना, प्रसिद्ध सॉफ्टवेअर डेव्हलपर केंट बेक सोप्या सॉफ्टवेअर डिझाइनच्या नियमांची यादी घेऊन आले.

केंट बेकच्या मते, एक चांगले सॉफ्टवेअर डिझाइनः

  • सर्व चाचण्या चालवतात
  • डुप्लिकेशन नाही
  • प्रोग्रामरचा हेतू व्यक्त करतो
  • वर्ग आणि पद्धतींची संख्या कमी करते

या लेखामध्ये, आम्ही व्यावहारिक iOS उदाहरणे देऊन आणि त्यांच्याकडून आम्हाला कसा फायदा होऊ शकतो याबद्दल चर्चा करून हे नियम iOS विकास जगाला कसे लागू करता येतील यावर चर्चा करू.

सर्व चाचण्या चालवतात

सॉफ्टवेअर डिझाइन आम्हाला अशी प्रणाली तयार करण्यात मदत करते जी हेतूनुसार कार्य करते. परंतु एखादी प्रणाली त्याच्या डिझाइनद्वारे सुरुवातीच्या हेतूनुसार कार्य करेल हे आम्ही कसे सत्यापित करू शकतो? उत्तर असे आहे की ते सत्यापित करणार्‍या चाचण्या तयार करुन आहेत.

दुर्दैवाने, iOS विकासात विश्वाच्या चाचण्या बर्‍याच वेळा टाळल्या जातात… परंतु एक डिझाइन केलेले सॉफ्टवेअर तयार करण्यासाठी, आपण नेहमीच चाचणी लक्षात घेऊन स्विफ्ट कोड लिहायला हवा.

चला चाचणी लेखन आणि सिस्टम डिझाइन सुलभ बनवू शकणार्‍या दोन तत्त्वांवर चर्चा करूया. आणि ते एकल जबाबदारीचे तत्त्व आणि अवलंबित्व इंजेक्शन आहेत.

एकल जबाबदारीचे तत्त्व (एसआरपी)

एसआरपी नमूद करते की वर्गात बदल करण्याचे एक कारण असले पाहिजे. एसआरपी हे सर्वात सोप्या तत्त्वांपैकी एक आहे आणि योग्य होण्यास सर्वात कठीण आहे. जबाबदा Mix्या मिसळणे ही एक गोष्ट आहे जी आपण नैसर्गिकरित्या करतो.

चला अशा काही कोडचे उदाहरण देऊ ज्याचे परीक्षण करणे खरोखर अवघड आहे आणि त्यानंतर एसआरपी वापरुन रिफाक्टर केले आहे. मग कोडची चाचणी कशी करता येईल यावर चर्चा करा.

समजा आम्हाला सध्याच्या आमच्या व्ह्यू व्ह्यू नियंत्रककडून पेमेंटव्यू कंट्रोलर सादर करण्याची आवश्यकता आहे, पेमेंट व्ह्यूकंट्रोलरने आमच्या देय उत्पादनांच्या किंमतीवर अवलंबून त्याचे दृष्य कॉन्फिगर केले पाहिजे. आमच्या बाबतीत, बाह्य वापरकर्त्याच्या काही घटनांवर अवलंबून किंमत बदलू शकते.

या अंमलबजावणीसाठी कोड सध्या खालीलप्रमाणे दिसत आहे:

आम्ही या कोडची चाचणी कशी करू शकतो? प्रथम आपण काय परीक्षण करावे? किंमतीची सूट योग्य प्रकारे मोजली जाते? सूटची चाचणी घेण्यासाठी आम्ही पेमेंट इव्हेंटची थट्टा कशी करू शकतो?

या वर्गासाठी लेखन चाचण्या क्लिष्ट असतील, आम्ही त्यास लिहिण्याचा एक चांगला मार्ग शोधला पाहिजे. बरं, प्रथम आपण एक मोठी समस्या सोडवूया. आपल्याला आपली अवलंबन कमी करण्याची आवश्यकता आहे.

आम्ही पाहतो की आमचे उत्पादन लोड करण्यासाठी आमच्याकडे तर्क आहे. आमच्याकडे पेमेंट इव्हेंट्स आहेत जे वापरकर्त्यास सूट घेण्यास पात्र ठरतात. आमच्याकडे सवलत, सूट गणना आणि यादी आहे.

तर हे फक्त स्विफ्ट कोडमध्ये भाषांतरित करण्याचा प्रयत्न करूया.

आम्ही एक पेमेंट मॅनेजर तयार केला आहे जो आमच्या पेमेंट्सशी संबंधित लॉजिक मॅनेज करते, आणि प्राइस कॅल्क्युलेटर विभक्त करते जे ते सहज चाचणीयोग्य आहे. तसेच, डेटा-लोडर जो आमची उत्पादने लोड करण्यासाठी नेटवर्क किंवा डेटाबेस परस्परसंवादासाठी जबाबदार आहे.

आम्ही सवलत व्यवस्थापित करण्यासाठी जबाबदार वर्गाची आवश्यकता असल्याचेही नमूद केले. चला त्यास कूपन मॅनेजर म्हणून कॉल करू आणि वापरकर्त्यास सवलत कूपन व्यवस्थापित करू.

आमचे देयक दृश्य नियंत्रक नंतर यासारखे दिसू शकतात:

आता यासारख्या चाचण्या लिहू शकतो

  • टेस्ट कॅल्क्युलेटिंग फाइनलप्रिसविथआउट कूपन
  • टेस्ट कॅल्क्युलेटिंग फाइनलप्रिसविथकूपन
  • testCouponExists

आणि इतर अनेक! आता स्वतंत्र वस्तू तयार करून आम्ही अनावश्यक डुप्लिकेशन टाळतो आणि त्यासाठी चाचण्या लिहिणे सोपे आहे असा एक कोड देखील तयार करतो.

अवलंबित्व इंजेक्शन

दुसरे तत्व म्हणजे अवलंबित्व इंजेक्शन. आणि आम्ही वरील उदाहरणांमधून पाहिले की आम्ही आधीच आपल्या ऑब्जेक्ट इनिशिएलायझर्सवर अवलंबन इंजेक्शन वापरले आहे.

वरील प्रमाणे आपली अवलंबन इंजेक्शन करण्याचे दोन मोठे फायदे आहेत. आमचे प्रकार कोणत्या अवलंबनांवर अवलंबून आहेत हे स्पष्ट करते आणि जेव्हा आम्हाला वास्तविक गोष्टीऐवजी चाचणी घेण्याची इच्छा असते तेव्हा आम्हाला मॉक ऑब्जेक्ट समाविष्ट करण्याची परवानगी देते.

आमच्या ऑब्जेक्ट्ससाठी प्रोटोकॉल तयार करणे आणि खालील प्रमाणे वास्तविक आणि मॉक ऑब्जेक्टद्वारे ठोस अंमलबजावणी प्रदान करणे हे एक चांगले तंत्र आहे:

अवलंबन म्हणून कोणता वर्ग लावायचा आहे हे आपण आता सहजपणे ठरवू शकतो.

घट्ट जोड्यामुळे चाचण्या लिहिणे कठीण होते. तर, त्याचप्रमाणे, आम्ही जितके अधिक परीक्षण लिहितो तितकेच आम्ही डीआयपीसारखी तत्त्वे वापरतो आणि जोड कमी करण्यासाठी कमीतकमी अवलंबन इंजेक्शन, इंटरफेस आणि अ‍ॅबस्ट्रॅक्शन सारख्या साधनांचा वापर करतो.

कोडला अधिक चाचणी करण्यायोग्य बनवण्यामुळे आपला ब्रेक होण्याची भीती तर दूर होतेच (कारण आम्ही त्या परीक्षेतून बॅक अप घेत आहोत) पण क्लीनर कोड लिहिण्यासही हातभार लागतो.

लेखाचा हा भाग वास्तविक एकक चाचणी लिहिण्यापेक्षा चाचणी घेण्यायोग्य कोड कसा लिहावा याबद्दल अधिक काळजी घेत होता. आपल्याला युनिट टेस्ट लिहिण्याबद्दल अधिक जाणून घ्यायचे असल्यास आपण हा लेख तपासू शकता जिथे मी चाचणी-चालित विकासाचा वापर करून जीवनाचा खेळ तयार करतो.

डुप्लिकेशन नाही

डुप्लिकेशन हे सुसज्ज केलेल्या प्रणालीचे प्राथमिक शत्रू आहे. हे अतिरिक्त काम, अतिरिक्त जोखीम दर्शवते, अनावश्यक गुंतागुंत जोडते.

या विभागात, आम्ही आयओएसमधील सामान्य डुप्लिकेशन काढून टाकण्यासाठी टेम्पलेट डिझाइन पॅटर्नचा वापर कसा करू शकतो यावर चर्चा करू. हे समजणे सोपे करण्यासाठी आम्ही वास्तविक जीवनातील गप्पांचे रिफाक्टर कार्यान्वयन करणार आहोत.

समजा आमच्याकडे सध्या आमच्या अॅपमध्ये एक मानक चॅट विभाग आहे. एक नवीन आवश्यकता समोर आली आहे आणि आता आम्हाला नवीन गप्पा - लाइव्ह-गप्पा लागू करायच्या आहेत. जास्तीत जास्त 20 संख्येसह संदेश असलेले गप्पा आणि आम्ही चॅट व्ह्यू डिसमिस केल्यावर हे चॅट अदृश्य होईल.

या चॅटमध्ये आमच्या वर्तमान गप्पांसारखेच दृश्ये असतील परंतु त्यास काही भिन्न नियम असतील:

  1. चॅट संदेश पाठविण्यासाठी नेटवर्क विनंती भिन्न असेल.

२. चॅट ​​मेसेजेस लहान असणे आवश्यक आहे, संदेशासाठी २० वर्णांपेक्षा जास्त नाही.

Chat. आमच्या स्थानिक डेटाबेसमध्ये चॅट संदेश कायम राहू नयेत.

समजा की आम्ही एमव्हीपी आर्किटेक्चर वापरत आहोत आणि आम्ही सध्या आमच्या प्रेझेंटरमध्ये गप्पा संदेश पाठवण्याचे लॉजिक हाताळतो. आमच्या थेट चॅट नावाच्या नवीन गप्पांसाठी नवीन नियम जोडण्याचा प्रयत्न करूया.

एक निष्कलंक अंमलबजावणी खालीलप्रमाणे असेल:

परंतु भविष्यात आपल्याकडे बर्‍याच प्रकारचे चॅट प्रकार असतील तर काय होईल?
जर आम्ही जोडत राहिलो तर प्रत्येक प्रकारात आमच्या गप्पांची स्थिती तपासली तर कोड वाचणे आणि राखणे अवघड होईल. तसेच, हे महत्प्रयासाने चाचणी करण्यायोग्य आहे आणि राज्य तपासणीचे सादरकर्त्याच्या संपूर्ण व्याप्तीवर डुप्लिकेट केले जाईल.

येथेच टेम्पलेट पैटर्न वापरात येते. जेव्हा आम्हाला अल्गोरिदमच्या एकाधिक अंमलबजावणीची आवश्यकता असते तेव्हा टेम्पलेट नमुना वापरला जातो. टेम्पलेट परिभाषित केले आहे आणि नंतर पुढील बदलांसह त्यास तयार केले आहे. जेव्हा बहुतेक उपशाखांना समान वर्तन अंमलात आणण्याची आवश्यकता असते तेव्हा ही पद्धत वापरा.

आम्ही गप्पा प्रेझेंटरसाठी एक प्रोटोकॉल तयार करू शकतो आणि आम्ही अशा पद्धती विभक्त करतो ज्या गप्पा प्रेझेंटर टप्प्याटप्प्याने ठोस वस्तूंनी वेगळ्या पद्धतीने लागू केल्या जातील.

आम्ही आता आयकॅटप्रसेन्टरशी आमचे प्रेझेंटर्स बनवू शकतो

आमचे प्रेझेंटर आता स्वत: च्या आत सामान्य फंक्शन्स कॉल करून मेसेज पाठवितो आणि वेगळ्या पद्धतीने कार्यान्वित होऊ शकतील अशी कार्ये सोपवितो.

आता आम्ही ऑब्जेक्ट्स तयार करा जे प्रीसेटर टप्प्यावर आधारित असतील आणि त्यांच्या गरजेनुसार ही कार्ये कॉन्फिगर करा.

आम्ही आमच्या व्ह्यू कंट्रोलरमध्ये अवलंबन इंजेक्शन वापरल्यास आम्ही आता दोन भिन्न प्रकरणांमध्ये समान दृश्य नियंत्रकाचा पुन्हा वापर करू शकतो.

डिझाईन पॅटर्न्स वापरुन आम्ही आपला आयओएस कोड खरोखर सुलभ करू शकतो. आपल्याला त्याबद्दल अधिक जाणून घेऊ इच्छित असल्यास, पुढील लेख पुढील स्पष्टीकरण प्रदान करेल.

भावपूर्ण

सॉफ्टवेअर प्रकल्पाचा बहुतांश खर्च हा दीर्घकालीन देखभालीसाठी आहे. सॉफ्टवेअर विकसकांसाठी कोड वाचणे आणि राखणे सोपे लिहिणे आवश्यक आहे.

आम्ही चांगले नामकरण, एसआरपी आणि लेखन चाचणी वापरुन अधिक अर्थपूर्ण कोड ऑफर करू शकतो.

नामकरण

कोडला अधिक अर्थपूर्ण बनवणारी एक गोष्ट - आणि ती नामकरण करीत आहे. नावे लिहिणे महत्त्वपूर्ण आहेः

  • हेतू प्रकट करा
  • विघटन करणे टाळा
  • सहज शोधण्यायोग्य आहेत

जेव्हा वर्ग आणि कार्ये नाम देण्याची वेळ येते तेव्हा वर्ग आणि वापरकर्ता क्रियापद किंवा क्रियापद वाक्यांशांच्या नावांसाठी एक संज्ञा किंवा संज्ञा-वाक्यांश वापरणे चांगले असते.

तसेच भिन्न डिझाइन नमुने वापरताना कधी कधी वर्गात नाव किंवा अभ्यागत यासारख्या नमुन्यांची नावे जोडणे चांगले. म्हणून वाचकांना तातडीने कळेल की त्यासंबंधित सर्व कोड वाचण्याची आवश्यकता नसताना तेथे कोणता नमुना वापरला जातो.

एसआरपी वापरणे

कोडला अर्थपूर्ण बनवणारी आणखी एक गोष्ट म्हणजे वरुन नमूद केलेले एकल जबाबदारीचे सिद्धांत वापरणे. आपण आपली कार्ये आणि वर्ग छोटे ठेवून आणि एकाच हेतूने व्यक्त करू शकता. लहान वर्ग आणि कार्ये सहसा नावे सोपे असतात, लिहिण्यास सोपे असतात आणि समजण्यास सुलभ असतात. फंक्शन फक्त एका उद्देशासाठी कार्य केले पाहिजे.

लेखन चाचणी

लेखन चाचण्यांमध्ये बरेच स्पष्टीकरण देखील मिळते, खासकरुन लेगसी कोडसह कार्य करताना. तसेच लिखित युनिट चाचण्या देखील अर्थपूर्ण असतात. चाचण्यांचे प्राथमिक लक्ष्य उदाहरणार्थ दस्तऐवजीकरण म्हणून कार्य करणे. आमच्या परीक्षांचे वाचन करणारे एखाद्यास वर्गात काय आहे हे द्रुतपणे समजण्यास सक्षम असावे.

वर्ग आणि पद्धतींची संख्या कमी करा

वर्गाची कार्ये कमी राहिली पाहिजेत, फंक्शनमध्ये नेहमीच एक गोष्ट केली पाहिजे. एखाद्या फंक्शनमध्ये बर्‍याच ओळी असल्यास त्या कदाचित दोन किंवा अधिक स्वतंत्र फंक्शन्समध्ये विभक्त केल्या जाणा actions्या कृती करत असतील.

एक चांगला दृष्टीकोन म्हणजे शारीरिक रेषा मोजणे आणि जास्तीत जास्त चार ते सहा ओळी कार्य करण्याचे लक्ष्य ठेवण्याचा प्रयत्न करणे, बहुतेक प्रकरणांमध्ये त्या ओळींच्या संख्येपेक्षा जास्त काही वाचणे आणि राखणे कठीण होऊ शकते.

आयओएसमधील एक चांगली कल्पना म्हणजे कॉन्फिगरेशन कॉल आपण सहजपणे व्ह्यूडिडलॉड किंवा व्ह्यूडिडआइड फंक्शनवर करतो.

अशाप्रकारे, प्रत्येक गोंधळ दृश्यास्पद डीडलॉड फंक्शनऐवजी प्रत्येक कार्य लहान आणि देखरेखीची असेल. त्याचप्रमाणे अ‍ॅप प्रतिनिधींसाठी देखील अर्ज करावा. आम्ही प्रत्येक कॉन्फिगरेशन ondidFinishLaunchingWithOptions मेथड आणि वेगळे कॉन्फिगरेशन फंक्शन्स किंवा त्याहूनही चांगले कॉन्फिगरेशन क्लासेस टाकणे टाळावे.

कार्ये सह, आपण ते लांब किंवा लहान ठेवत आहोत की नाही हे मोजणे थोडे सोपे आहे, आपण बर्‍याच वेळा भौतिक ओळी मोजण्यावर अवलंबून राहू शकतो. वर्गांसह आम्ही भिन्न उपाय वापरतो. आम्ही जबाबदा count्या मोजतो. जर वर्गात फक्त पाच पद्धती असतील तर याचा अर्थ असा नाही की वर्ग लहान आहे असे असू शकते की त्या त्या पद्धतींवर बर्‍याच जबाबदा .्या आहेत.

आयओएस मधील एक ज्ञात समस्या म्हणजे यूआयव्हीयूकंट्रोलरचा मोठा आकार. हे खरे आहे की appleपल व्यू कंट्रोलर डिझाइनद्वारे या वस्तू एकाच उद्देशाने ठेवणे कठीण आहे परंतु आपण आपल्या प्रयत्नांनी प्रयत्न केले पाहिजेत.

यूआयव्हीयूकंट्रोलरला लहान बनवण्याचे बरेच मार्ग आहेत माझे मत म्हणजे एक आर्किटेक्चर वापरणे ज्यामध्ये व्हीआयपीईआर किंवा एमव्हीपी सारख्या चिंतेचे अधिक चांगले विभाजन असेल परंतु याचा अर्थ असा नाही की आम्ही appleपल एमव्हीसीमध्ये देखील त्यास चांगले बनवू शकत नाही.

अनेक चिंता दूर करण्याचा प्रयत्न करून आम्ही कोणत्याही आर्किटेक्चरसह सुंदर सभ्य कोड पोहोचू शकतो. एकल-हेतू वर्ग तयार करण्याची कल्पना आहे जी दृश्या नियंत्रकांसाठी मदतनीस म्हणून काम करेल आणि कोड अधिक वाचनीय आणि चाचणीयोग्य बनवेल.

काही गोष्टी ज्या नियंत्रकांकडे कोणत्याही सबबशिवाय सहजपणे टाळल्या जाऊ शकतातः

  • नेटवर्क कोड लिहिण्याऐवजी नेटवर्क कॉलसाठी जबाबदार असलेला एक नेटवर्कमॅनेजर असावा
  • व्ह्यू कंट्रोलर्समध्ये डेटा हाताळण्याऐवजी आम्ही फक्त त्यासाठी जबाबदार असलेला डेटा मॅनेजर एक क्लास तयार करू शकतो.
  • यूआयव्हीयूकंट्रोलरमध्ये यूजरडिफाल्ट्स तारांसह खेळण्याऐवजी आम्ही त्यावरील एक मुखवटा तयार करू शकतो.

अनुमान मध्ये

माझा असा विश्वास आहे की आम्ही अशा घटकांकडील सॉफ्टवेअर तयार केले पाहिजेत ज्या एका नावासाठी अचूक नावांनी, साध्या, लहान, जबाबदार आणि पुन्हा वापरण्यायोग्य असतील.

या लेखात, आम्ही केंट बेक यांनी साध्या डिझाइनच्या चार नियमांवर चर्चा केली आणि आम्ही त्यांना iOS विकास वातावरणात कसे लागू करू शकतो याची व्यावहारिक उदाहरणे दिली.

आपण या लेखाचा आनंद घेतल्यास आपला पाठिंबा दर्शविण्यासाठी टाळ्या वाजवण्याची खात्री करा. आणखी बरेच लेख पाहण्यासाठी माझे अनुसरण करा जे आपले iOS विकसक कौशल्य पुढील स्तरावर नेतील.

आपल्याकडे काही प्रश्न किंवा टिप्पण्या असल्यास मोकळ्या मनाने एक चिठ्ठी येथे ठेवा किंवा मला arlindaliu.dev@gmail.com वर ईमेल करा.