अनिवार्य के निहित वापस पकड़

ऑब्जेक्ट-उन्मुख प्रतिमान व्यवसाय के लिए बेहद सुविधाजनक है: यह आपको लगभग किसी भी विचार को लागू करने की अनुमति देता है, स्वीकार्य उत्पाद प्रदर्शन प्रदान करता है। इस मामले में, उत्पाद से हमारा मतलब एक iOS एप्लिकेशन है, इसलिए, निष्कर्ष में, हम इस मंच पर विशेष रूप से विकास से आगे बढ़ेंगे।

इस लोकप्रिय प्रतिमान की अच्छी तरह से ज्ञात कमियों की ओर आंखें फेर लेने से, इसके minuses की सूची में इसका सबसे महत्वपूर्ण लाभ - विकास का लचीलापन शामिल है। यह माइनस क्यों है? यह काफी स्पष्ट है कि लचीलेपन, व्यावसायिक समस्याओं को हल करने की मूल क्षमता के अलावा, विभिन्न तरीकों से ऐसा करना संभव बनाता है। यह सही है कि एक सही दृष्टिकोण के लिए एक दर्जन गलत हैं, इस तथ्य के बावजूद कि किसी भी मामले में व्यावसायिक कार्य को सही ढंग से हल किया जाएगा, लेकिन कार्यान्वयन में अंतर के साथ, एक्स्टेंसिबिलिटी और पारदर्शिता पहले से ही लागू दृष्टिकोण की शुद्धता पर निर्भर करेगी।

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

बात सरल है। चलो अगले स्वयंसिद्ध से धक्का देते हैं - अधिक गुण एक वस्तु में हैं, "बदतर" यह है। इस कथन को निम्नानुसार समझाया जा सकता है: आंतरिक स्थिति की संख्या में वृद्धि के साथ, वस्तु के सभी सकारात्मक संकेतक - विलुप्ति, प्रतिरूपता, पारदर्शिता, परीक्षणशीलता - कमी। एक आपत्ति कर सकता है, यह कहते हुए कि वस्तु की जटिलता और उसकी कार्यक्षमता आपस में जुड़ी हुई है और पहली के बिना, दूसरी नहीं होती है। सब कुछ सच है, लेकिन, "स्टेटफुल" पथ का पालन करते हुए, जटिलता का विकास तेजी से होता है, जबकि आदर्श रूप से विकास रैखिक होना चाहिए, या, अधिक बस, एक नई सुविधा को मौजूदा सुविधाओं को जटिल नहीं करना चाहिए।

PS यहाँ यह स्पष्ट करने योग्य है कि सुविधाओं को व्यावसायिक रूप से संबंधित तर्क की परतों के रूप में समझा जाता है, इसलिए एक नया वर्ग बनाने के बजाय एक मौजूदा वर्ग को जटिल बनाने के लिए अक्सर निर्णय लिया जाता है। ऐसे मामलों में, पहले SOLID सिद्धांत के विरोधाभासों को खोजना मुश्किल है।

एक विकल्प के साथ संस्थाओं की सूची के साथ एक उदाहरण पूरी तरह से मानक स्क्रीन है। गुणों में से कुछ को गैर-स्थिर बनाया जा सकता है, लेकिन आईबी हमें नियंत्रक के डिफ़ॉल्ट निर्माता से बांधता है और यह हमें "गंदगी" के लिए मजबूर करता है। इन गुणों तक पहुंच एक ही फ़ाइल के भीतर प्रत्येक वर्ग विधि द्वारा प्राप्त की जाती है। और सबसे अप्रिय क्षण यह है कि उनकी उत्परिवर्तन भी कुछ भी नहीं है, और यह किसी भी तरह एक मजबूत संबंध के रूप में अपरिवर्तनीय परिणाम की ओर जाता है और, परिणामस्वरूप, इस तथ्य के लिए कि कुछ दोषों का निर्धारण नए लोगों की उपस्थिति का कारण बनता है:



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



एक उदाहरण के रूप में UIKit का उपयोग करते हुए, आप वास्तव में देख सकते हैं कि विकास की अनिवार्य शैली कोड की जटिलता को कैसे प्रभावित करती है और वर्गों में "बलों" गुणों को किस बिंदु पर बनाया जाता है।
सबसे सरल मामला - एक बटन दबाने की प्रक्रिया - "गंदे तरीके" को परिभाषित करके केवल मानक रूप से किया जाता है, अर्थात्, एक फ़ंक्शन द्वारा जो कुछ भी उपयोगी नहीं प्राप्त कर सकता है, इसलिए आपको गुणों का उपयोग करने के लिए बाहर जाना होगा:



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



क्या यह सुविधाजनक है? आसानी से, सभी के पास हमेशा डेटा तक पहुंच होती है। लचीला, तेज, अनिवार्य। लेकिन यह सब समय के साथ, एक नियम के रूप में, कोड की एक हजार लाइनों के लिए एक ठोस ओबिलिस्क में और उन लोगों के आँसू में बदल जाता है, जिन्हें इस वर्ग में काम करने का काम मिला।

सीमाओं पर लौटते हुए, निम्न सिद्धांत को ऊपर से बनाया जा सकता है - कक्षाओं में गुणों के बिना कोड बहुत क्लीनर है, और समर्थन और विस्तार के साथ अधिक लाभदायक है। आदर्श रूप में, वस्तु का तर्क उसके "शुद्ध" तरीकों में होना चाहिए, जो इनपुट के रूप में उनकी सभी निर्भरता लेते हैं और आउटपुट पर उनकी गतिविधि का परिणाम है।
विचार वस्तु की निजी स्थिति को एक स्तर कम करना है। यही है, अगर निजी बाहरी दुनिया से संपत्तियों को बंद कर देता है, तो हमारा कार्य आगे भी जाना है और तरीकों के स्तर के लिए एनकैप्सुलेशन को मजबूत करना है। पहली नज़र में, मंच के सभी अतुल्यकालिक प्रकृति और मुख्य ढांचे की अपरिपक्वता के लिए, ऐसा लग सकता है कि यह पूरा विचार न केवल असंभव है, लेकिन कम से कम इसके कार्यान्वयन में अप्राकृतिक महसूस होगा। और, सबसे अधिक संभावना है कि यह ऐसा होगा, लेकिन यह उन समस्याओं में से एक है जो अतिरिक्त स्तर के अमूर्त को पेश करके हल किया जा सकता है।

यदि हम गुणों का सहारा लिए बिना वर्गों के सभी तर्कों को उनके तरीकों में फिट करना चाहते हैं, तो हमें निकटता के साथ मिलकर काम करने की आवश्यकता है। IOS के पास अतुल्यकालिक संचालन के प्रबंधन के लिए मानक उपकरण हैं, जैसे कि GCD और OperationQueue। ऐसा लगता है कि वे पर्याप्त होंगे, लेकिन जब आप विचार को जीवन में लाने की कोशिश करते हैं, तो सब कुछ उतना ही स्पष्ट हो जाएगा जितना आप चाहते हैं कि उतने ही रौनक से दूर रहें। इस दृष्टिकोण के साथ, इस तथ्य के अलावा कि कॉलबैक-नरक प्राप्त करने का एक बड़ा मौका है, कोड खुद ही बोझिल हो जाएगा, इसमें कई तार्किक छेद होंगे और यह दृढ़ता से जुड़ा होगा। यह संभव है कि इस तरह के एक कोड से भी अधिक जटिल हो जाएगा जो हम भागने की इतनी जल्दी कोशिश कर रहे हैं।

यदि आप चारों ओर देखते हैं, तो आप देख सकते हैं कि इस लक्ष्य को प्राप्त करने के लिए बहुत अधिक सुंदर और कार्यात्मक तरीके हैं। प्रतिक्रियाशील प्रोग्रामिंग लंबे समय से वाणिज्यिक सॉफ्टवेयर विकास में उपयोग की गई है और अतुल्यकालिक फ्रंट-एंड दुनिया के लिए आदर्श है। इस मामले में, हम स्विफ्ट - आरएक्स के लिए प्रतिक्रियाशील प्रतिमान के एक (बल्कि सफल) कार्यान्वयन पर विचार करेंगे।



यह ऑब्जर्वेबल नामक एक साधारण इकाई प्रदान करता है। यह घटनाओं के प्रवाह पर एक प्रकार का अमूर्तता है, इसे सब्सक्राइब किया जा सकता है और इसके बाद ग्राहक को ये इवेंट समय पर प्राप्त होंगे:



घटनाओं के प्रवाह की कल्पना करने का सबसे आसान तरीका एक नियमित बटन पेश करना है। इसके संचालन की घटना यहां एक धारा है, इसलिए कोई भी वस्तु क्लिक करने की घटनाओं को सदस्यता और प्राप्त कर सकती है, और सबसे महत्वपूर्ण बात, बटन को अपने स्वयं के ग्राहकों के बारे में कुछ भी नहीं पता है। आसानी से, लगभग किसी भी कार्रवाई को मूल्यों के समान अनुक्रम में बदल दिया जा सकता है, और यह महत्वपूर्ण है, क्योंकि ऑब्जर्वेबल को एक दूसरे के साथ जोड़ा जा सकता है, क्योंकि कोई भी मानक फ्रेमवर्क संभव नहीं होगा।

उदाहरण के लिए, आप बटन दबाकर (डबल टैप को फ़िल्टर करके) कई अनुरोध भेज सकते हैं, उनमें से प्रत्येक का जवाब देने के लिए प्रतीक्षा करें, फिर उस उत्तर को संयोजित करें जो उपयोगकर्ता ने स्क्रीन पर दर्ज किया है, दूसरे अनुरोध को निष्पादित करें और अगली स्क्रीन पर जाएं, परिणाम को स्थानांतरित करते हुए, जब यह Rx स्क्रीन से बाहर निकलने पर त्रुटियों को आसानी से संभालने और इस श्रृंखला को पूरा करने (अनुरोधों को रद्द करने) को पूरा करने के लिए संभव बना देगा, और यह सभी तर्क टाइप किए गए कोड की दो दर्जन लाइनें लेगा:



यह निपटान की एकमात्र संपत्ति के बारे में बात करने लायक है। जैसा कि स्क्रीनशॉट से देखा जा सकता है, प्रत्येक सदस्यता को इसमें रखा गया है, और यह उनके जीवनकाल को नियंत्रित करने के लिए आवश्यक है। यही है, सब्सक्रिप्शन तब तक मान्य है जब तक "बैग" रहता है जिसमें वे इस मामले में, जबकि नियंत्रक रहता है।

कॉम्पैक्टनेस के अलावा, ऊपर दिए गए कोड में एक गलती करना मुश्किल है, क्योंकि प्रत्येक क्लोजर कुछ वापस करता है और साइड इफेक्ट्स नहीं होता है। यह वह शक्ति है जिसकी हम तलाश कर रहे थे।

आप एक और महत्वपूर्ण बिंदु को नोटिस कर सकते हैं: चूंकि वर्ग में कोई गुण नहीं है, इसलिए [कमजोर स्वयं] लिखना आवश्यक नहीं है, जो कोड की पठनीयता को सकारात्मक रूप से प्रभावित करता है। सभी कार्यों को और बेहतर तरीके से स्थानीय तरीके से परिभाषित किया जा सकता है जहां उनका उपयोग किया जाता है, या अलग-अलग कक्षाओं में निकाला जाता है। वैसे, इस मामले में निर्भरता (ViewModel, प्रस्तुतकर्ता, आदि) के लिंक को नियंत्रक विधि के तर्क के रूप में पारित किया जा सकता है, इस मामले में उन्हें गुणों में सहेजने की आवश्यकता नहीं है। यह सही है।

समीक्षा करने के बाद, यह सरलीकरण विकास के लिए अवलोकन का उपयोग करने का समय है। बिल्कुल कैसे? आइए हम "स्वच्छ" विधियों के विचार पर लौटते हैं और अपनी एकमात्र विधि में एक छोटे पर्दे के तर्क को लागू करने का प्रयास करते हैं। स्पष्टता के लिए, हम दृश्य के लोडिंग को समाप्त करने की विधि का चयन करेंगे (देखेंडीडलॉड)। स्वाभाविक रूप से, यदि स्क्रीन आईबी में बनाई गई है, तो हमें आउटलेट के लिए गुण बनाने होंगे, लेकिन यह डरावना नहीं है, क्योंकि तत्व स्वयं व्यावसायिक तर्क का प्रतिनिधित्व नहीं करते हैं, इसलिए वे स्क्रीन की जटिलता को बहुत प्रभावित नहीं करेंगे। लेकिन अगर स्क्रीन कोड से बना है, तो आप बिल्कुल भी गुणों के बिना कर सकते हैं (डिस्पोज़बग को छोड़कर), हमारी विधि में तत्व बना सकते हैं और उन्हें वहीं उपयोग कर सकते हैं। उन UIKit तत्वों की अपरिपक्वता के बारे में जो पहले वर्णित थे? आरएक्स, स्वयं दृष्टिकोण के अलावा, मानक यूआई घटकों के लिए प्रतिक्रियाशील आवरण प्रदान करता है, इसलिए ज्यादातर मामलों में आप मौके पर घटनाओं के आवश्यक अनुक्रम प्राप्त कर सकते हैं। या, इसके विपरीत, मौजूदा ऑब्जर्वेबल को, उदाहरण के लिए, एक तालिका से बांधें - एक अनुरोध करें ताकि वह अपनी सामग्री को उसके पूरा होने के तुरंत बाद अपडेट करे:



संग्रह के लिए बाइंडिंग काफी लचीला है, लेकिन डिफ़ॉल्ट रूप से, यह केवल रीलोडडाटा के माध्यम से काम करता है। बिंदु अद्यतन के लिए एक ही लेखक से एक अद्भुत डीबग की गई लाइब्रेरी है - RxDataSources। इसके साथ, आप बैचअप के दौरान क्रैश के बारे में भूल सकते हैं।

आगे क्या होगा? एक एकल स्क्रीन विधि विकसित होगी और एक जटिल मामले में, इसे बनाए रखना मुश्किल हो जाएगा। और जब ऐसा होता है, तो यह अचानक स्पष्ट हो जाता है कि यह विधि स्वयं के अलावा किसी अन्य चीज पर निर्भर नहीं करती है, और प्रतिक्रियात्मक दृष्टिकोण ने कोड को तार्किक ब्लॉकों में विभाजित किया है जो आसानी से अलग-अलग वस्तुओं में समान तरीके से डिजाइन करके डाल सकते हैं। लेकिन इस बार, विधियाँ पहले ही स्क्रीन पर कुछ निर्भरताएँ ले लेंगी और कुछ परिणाम वापस लौटाएंगी। सकारात्मक बिंदु यह है कि इस मामले में हस्ताक्षर यथासंभव सामग्री प्राप्त किए जाते हैं, यह देखा जा सकता है कि फ़ंक्शन को अपने काम की आवश्यकता है और इसका परिणाम क्या है। यह कुछ इस तरह दिख सकता है:



अलग-अलग संरचनाएं पठनीय और साफ-सुथरी विधि को बनाए रखने में मदद करती हैं, क्योंकि कई निर्भरताएं हो सकती हैं।

यह समझना महत्वपूर्ण है कि विधि पूरे ऑब्जेक्ट में केवल एक ही नहीं होनी चाहिए, एक दूसरे से उनकी स्वतंत्रता का सार। आरएक्स के लिए धन्यवाद, उनका इनपुट और आउटपुट अतुल्यकालिक हो सकता है और डेटा हेरफेर के लिए एक और आयाम प्रदान करते हुए एक या एक से अधिक ऑब्जर्वेबल का प्रतिनिधित्व कर सकता है।

यह दृष्टिकोण आपके हाथों को खोल देता है और आपको उनके कोड को स्पष्ट और शिथिल युग्मित बनाए रखते हुए लगभग किसी भी जटिलता की स्क्रीन को लागू करने की अनुमति देता है।