तीन साल पहले, मैंने स्विफ्ट भाषा के लिए DI लाइब्रेरी के बारे में एक लेख लिखा था। तब से, लाइब्रेरी बहुत बदल गई है और कई मायनों में इसे पार करते हुए, Swinject के लिए अपने तरह के योग्य प्रतियोगी बन गए हैं। लेख पुस्तकालय की क्षमताओं के लिए समर्पित है, लेकिन सैद्धांतिक विचार भी हैं। इसलिए, जो DI, DIP, IoC के विषयों में रुचि रखते हैं, या जो Swinject और Swinject के बीच चयन करते हैं, मैं बिल्ली से पूछता हूं:

DIP, IoC क्या है और इसके साथ क्या खाते हैं?

डीआईपी और आईओसी का सिद्धांत

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

उन विषयों में से एक जो लोग साक्षात्कार के लिए पूछना चाहते हैं, वह है SOLID । कोई भी लेख उसके बारे में बिल्कुल नहीं है, घबराएं नहीं। लेकिन हमें एक पत्र की आवश्यकता है, क्योंकि यह मेरे पुस्तकालय से निकटता से संबंधित है। यह पत्र `डी` - निर्भरता उलटा सिद्धांत है।

निर्भरता उलटा सिद्धांत बताता है:

• ऊपरी स्तर के मॉड्यूल को निचले स्तर के मॉड्यूल पर निर्भर नहीं होना चाहिए। दोनों प्रकार के मॉड्यूल को अमूर्तता पर निर्भर होना चाहिए।
• विवरण विवरण पर निर्भर नहीं होना चाहिए। विवरण अमूर्तता पर निर्भर होना चाहिए।

कई लोग गलती से मान लेते हैं कि यदि वे प्रोटोकॉल / इंटरफेस का उपयोग करते हैं, तो वे स्वचालित रूप से इस सिद्धांत का पालन करते हैं, लेकिन यह पूरी तरह से सच नहीं है।

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

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

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

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

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



लेकिन तर्क करने में त्रुटि कहाँ है? समस्या यह है कि वर्णित कनेक्शन, प्रोटोकॉल की उपलब्धता के बावजूद, वास्तव में एक "विस्तार" है - एक "विस्तार"। अधिक सटीक रूप से, किस नाम और कहाँ प्रोटोकॉल इंजन स्थित है।

अब सही अन्य विकल्प पर विचार करें।

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



अब एक और मामले के साथ एक सादृश्य बनाते हैं, क्योंकि ये तर्क स्पष्ट नहीं हो सकते हैं।

एक बैकएंड है और इससे कुछ कार्यक्षमता की आवश्यकता है। बैकएंड हमें एक बड़ी विधि देता है जिसमें डेटा का एक गुच्छा होता है, और कहता है - "आपको 1000 में से इन 3 क्षेत्रों की आवश्यकता है"


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

और फिर DI क्या है

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

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

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

पुस्तकालय का इतिहास

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

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

आइए समझते हैं कि एक अच्छा DI पुस्तकालय क्या है:

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

यह इन सिद्धांतों है कि मैं पुस्तकालय के पूरे विकास का पालन करने की कोशिश करता हूं।

पुस्तकालय की विशेषताएं और लाभ

सबसे पहले, रिपॉजिटरी का एक लिंक: github.com/ivlevAstef/DITranquillity

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

यह मुझे ठीक लगता है। कार्यक्रम के निष्पादन के दौरान कोई दुर्घटना नहीं होती है, यदि प्रोग्रामर कुछ भूल गया, तो यह तुरंत रिपोर्ट किया जाएगा।

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

लेकिन यह सब पुस्तकालय का दावा नहीं है:

• पूर्ण धागा-सुरक्षा - किसी भी धागे से कोई भी ऑपरेशन किया जा सकता है और सब कुछ काम करेगा। अधिकांश लोगों को इसकी आवश्यकता नहीं है, इसलिए थ्रेड-सेफ्टी के संदर्भ में, निष्पादन की गति को अनुकूलित करने के लिए काम किया गया था। लेकिन प्रतियोगी पुस्तकालय, वादों के बावजूद, यदि आप एक ही समय में एक वस्तु को पंजीकृत करना और प्राप्त करना शुरू करते हैं तो गिर जाता है
• तेजी से निष्पादन की गति। एक वास्तविक डिवाइस पर, DITranquillity अपने प्रतिद्वंद्वी की तुलना में दोगुनी है। सिम्युलेटर पर सच है, निष्पादन की गति लगभग बराबर है। टेस्ट लिंक
• छोटे आकार - लाइब्रेरी का वजन Swinject + SwinjectStoryboad + SwinjectAutoregistration से कम होता है, लेकिन क्षमताओं में इस बंडल से आगे निकल जाता है
• एक संक्षिप्त, संक्षिप्त नोट, हालांकि नशे की लत
• पदानुक्रम। बड़ी परियोजनाओं के लिए, जिसमें कई मॉड्यूल शामिल हैं, यह एक बहुत बड़ा प्लस है, क्योंकि लाइब्रेरी वर्तमान मॉड्यूल से दूरी के द्वारा आवश्यक कक्षाएं ढूंढने में सक्षम है। यही है, यदि आपके पास प्रत्येक मॉड्यूल में एक प्रोटोकॉल का अपना कार्यान्वयन है, तो प्रत्येक मॉड्यूल में आपको कोई भी प्रयास किए बिना वांछित कार्यान्वयन मिलेगा

प्रदर्शन

और तो चलिए शुरू करते हैं। पिछली बार के रूप में इस परियोजना पर विचार किया जाएगा: SampleHabr । मैंने विशेष रूप से उदाहरण बदलना शुरू नहीं किया है - इसलिए आप तुलना कर सकते हैं कि सब कुछ कैसे बदल गया है। और उदाहरण पुस्तकालय की कई विशेषताओं को प्रदर्शित करता है।

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

पहले हमें एक ढांचा बनाने की जरूरत है (वैकल्पिक):

public class AppFramework: DIFramework { //   public static func load(container: DIContainer) { //     } } 

और कार्यक्रम की शुरुआत में, इस ढांचे को जोड़ने के साथ, अपना खुद का कंटेनर बनाएं:

 let container = DIContainer() //   container.append(framework: AppFramework.self) //     . //          ifdef DEBUG      ,         ,     . if !container.validate() { fatalError() } 

स्टोरीबोर्ड

अगला, आपको एक मूल स्क्रीन बनाने की आवश्यकता है। आमतौर पर इसके लिए स्टोरीबोर्ड का उपयोग किया जाता है, और इस उदाहरण में मैं इसका उपयोग करूंगा, लेकिन कोई भी UIViewControllers का उपयोग करने के लिए परेशान नहीं करता है।

के साथ शुरू करने के लिए, हमें एक स्टोरीबोर्ड पंजीकृत करना होगा। ऐसा करने के लिए, एक "भाग" बनाएं (वैकल्पिक - आप फ्रेमवर्क में सभी कोड लिख सकते हैं) इसमें दर्ज स्टोरीबोर्ड के साथ:

 import DITranquillity class AppPart: DIPart { static func load(container: DIContainer) { container.registerStoryboard(name: "Main", bundle: nil) .lifetime(.single) //   -    . } } 

और AppFramework में एक हिस्सा जोड़ें:

 container.append(part: AppPart.self) 

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

अब केवल एक चीज बची है वह है स्टोरीबोर्ड बनाना और स्टार्ट स्क्रीन दिखाना। कंटेनर की जाँच के बाद, यह AppDelegate में किया जाता है:

 window = UIWindow(frame: UIScreen.main.bounds) ///  Storyboard let storyboard: UIStoryboard = container.resolve(name: "Main") window!.rootViewController = storyboard.instantiateInitialViewController() window!.makeKeyAndVisible() 

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

प्रस्तुतकर्ता और ViewController

स्क्रीन पर ही जाएं। हम जटिल आर्किटेक्चर के साथ प्रोजेक्ट को लोड नहीं करेंगे, लेकिन हम सामान्य एमवीपी का उपयोग करेंगे। इसके अलावा, मैं बहुत आलसी हूं कि मैं प्रस्तोता के लिए एक प्रोटोकॉल नहीं बनाऊंगा। प्रोटोकॉल एक और वर्ग के लिए थोड़ा बाद में होगा, यहां प्रस्तुतकर्ता और ViewController को रजिस्टर और लिंक करने का तरीका दिखाना महत्वपूर्ण है।

ऐसा करने के लिए, AppPart में निम्न कोड जोड़ें:

 container.register(YourPresenter.init) container.register(YourViewController.self) .injection(\.presenter) //   

ये तीन लाइनें हमें दो वर्गों को पंजीकृत करने और उनके बीच संबंध स्थापित करने की अनुमति देंगी।

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

हम आवेदन शुरू करते हैं, और सब कुछ काम करता है, सभी कक्षाएं बनाई जाती हैं।

डेटा

खैर, अब हमें सर्वर से डेटा प्राप्त करने के लिए एक वर्ग और प्रोटोकॉल जोड़ने की आवश्यकता है:

 public protocol Server { func get(method: String) -> Data? } class ServerImpl: Server { init(domain: String) { ... } func get(method: String) -> Data? { ... } } 

और सुंदरता के लिए, हम सर्वर के लिए एक अलग सर्वरपार्ट डीआई क्लास बनाएंगे, जिसमें हम इसे पंजीकृत करते हैं। मैं आपको याद दिलाता हूं कि यह आवश्यक नहीं है और सीधे कंटेनर में पंजीकृत किया जा सकता है, लेकिन हम आसान तरीकों की तलाश नहीं कर रहे हैं :)

 import DITranquillity class ServerPart: DIPart { static func load(container: DIContainer) { container.register{ ServerImpl(domain: "https://github.com/") } .as(check: Server.self){$0} .lifetime(.single) } } 

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

दूसरे, वहाँ `as` फ़ंक्शन है - यह कहता है कि वर्ग किसी अन्य प्रकार - प्रोटोकॉल द्वारा सुलभ होगा। `{$ 0}` के रूप में इस ऑपरेशन का अजीब अंत `चेक:` नाम का हिस्सा है। यही है, यह कोड सुनिश्चित करता है कि ServerImpl सर्वर का उत्तराधिकारी है। लेकिन एक और वाक्य रचना है: `as (Server.self)` जो एक ही करेगा, लेकिन बिना जाँच के। यह देखने के लिए कि संकलक दोनों मामलों में क्या उत्पादन करेगा, आप प्रोटोकॉल कार्यान्वयन को निकाल सकते हैं।

कई `as` फ़ंक्शंस हो सकते हैं - इसका मतलब यह होगा कि प्रकार इनमें से किसी भी नाम से उपलब्ध है। मैं आपका ध्यान आकर्षित करता हूं कि यह एक पंजीकरण होगा, जिसका अर्थ है कि यदि वर्ग एक सिंगलटन है, तो वही उदाहरण आपके निर्दिष्ट प्रकार के लिए उपलब्ध होगा।

सिद्धांत रूप में, यदि आप प्रकार के कार्यान्वयन के द्वारा एक वर्ग बनाने की संभावना से खुद को बचाना चाहते हैं, या आपको इस वाक्य-विन्यास की अभी तक आदत नहीं है, तो आप लिख सकते हैं:

 container.register{ ServerImpl(domain: "https://github.com/") as Server } 

जो कुछ समान होगा, लेकिन कई अलग-अलग प्रकारों को निर्दिष्ट करने की क्षमता के बिना।

अब आप प्रस्तुतकर्ता में सर्वर को लागू कर सकते हैं, इसके लिए हम प्रस्तुतकर्ता को ठीक कर देंगे ताकि यह सर्वर को स्वीकार करे:

  class YourPresenter { init(server: Server) { ... } } 

हम कार्यक्रम शुरू करते हैं, और यह AppDelegate में `मान्य` कार्यों पर पड़ता है, इस संदेश के साथ कि टाइप` सर्वर` नहीं मिला, लेकिन यह `YourPresenter` द्वारा आवश्यक है। क्या हो रहा है? कृपया ध्यान दें कि कार्यक्रम के निष्पादन की शुरुआत में त्रुटि हुई थी, न कि पोस्ट फैक्टम। और कारण काफी सरल है - वे `AppFramework`:` ServerPart` को जोड़ना भूल गए:

 container.append(part: ServerPart.self) 

हम शुरू करते हैं - सब कुछ काम करता है।

लकड़हारा

इससे पहले, ऐसे अवसरों के साथ एक परिचित था जो बहुत प्रभावशाली नहीं हैं और कई के पास है। अब एक प्रदर्शन होगा कि स्विफ्ट पर अन्य पुस्तकालय नहीं जानते कि कैसे।

लकड़हारा के तहत एक अलग प्रोजेक्ट बनाया गया था।

पहले, आइए समझते हैं कि लकड़हारा क्या होगा। शैक्षिक उद्देश्यों के लिए, हम एक चालित प्रणाली नहीं करेंगे, इसलिए लकड़हारा एक विधि और कई कार्यान्वयन वाला एक प्रोटोकॉल है:

 public protocol Logger { func log(_ msg: String) } class ConsoleLogger: Logger { func log(_ msg: String) { ... } } class FileLogger: Logger { init(file: String) { ... } func log(_ msg: String) { ... } } class ServerLogger: Logger { init(server: String) { ... } func log(_ msg: String) { ... } } class MainLogger: Logger { init(loggers: [Logger]) { ... } func log(_ msg: String) { ... } } 

कुल, हमारे पास है:

• सार्वजनिक प्रोटोकॉल
• 3 विभिन्न लकड़हारा कार्यान्वयन, जिनमें से प्रत्येक एक अलग जगह पर लिखता है
• एक केंद्रीय लकड़हारा जो लॉगिंग फ़ंक्शन को अन्य सभी के लिए कहता है

प्रोजेक्ट ने 'लोगगरफ्रॉमवर्क' और 'लोगगरपार्ट' बनाया। मैं उनका कोड नहीं लिखूंगा, लेकिन मैं केवल 'लकड़हारा' के आंतरिक लेख लिखूंगा:

 container.register{ ConsoleLogger() } .as(Logger.self) .lifetime(.single) container.register{ FileLogger(file: "file.log") } .as(Logger.self) .lifetime(.single) container.register{ ServerLogger(server: "http://server.com/") } .as(Logger.self) .lifetime(.single) container.register{ MainLogger(loggers: many($0)) } .as(Logger.self) .default() .lifetime(.single) 

हमने पहले 3 पंजीकरण देखे हैं, और अंतिम प्रश्न उठाते हैं।

इनपुट के लिए एक पैरामीटर पास किया जाता है। प्रस्तुतकर्ता बनाए जाने पर एक समान पहले से ही दिखाया गया था, हालांकि एक संक्षिप्त रिकॉर्ड था - `इनिट` विधि का उपयोग केवल किया गया था, लेकिन कोई भी इस तरह लिखने के लिए परेशान नहीं करता है:

 container.register { YourPresenter(server: $0) } 

यदि कई पैरामीटर थे, तो कोई `$ 1`,` $ 2`, `$ 3`, आदि का उपयोग कर सकता है। 16 तक।

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

टैग, बदले में, एक अलग प्रकार है जिसे उपयोग के दौरान और पंजीकरण के दौरान निर्दिष्ट किया जाना चाहिए। अर्थात्, यदि अतिरिक्त मूल प्रकार नहीं हैं, तो टैग अतिरिक्त मापदंड हैं।

आप इसके बारे में अधिक पढ़ सकते हैं: संशोधक

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

ठीक है, हम YourPresenter में एक लकड़हारा पेश करके सुविधाओं की प्रस्तुति को समाप्त करेंगे:

 container.register(YourPresenter.init) .injection { $0.logger = $1 } 

यहाँ, उदाहरण के लिए, यह पहले की तुलना में थोड़ा अलग लिखा गया है - यह एक अलग वाक्यविन्यास के उदाहरण के लिए किया जाता है।

कृपया ध्यान दें कि लकड़हारा संपत्ति वैकल्पिक है:

 internal var logger: Logger? 

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

परिणाम

परिणाम पिछली बार के समान हैं, केवल सिंटैक्स कम और अधिक कार्यात्मक हो गया है।

क्या समीक्षा की गई:

• संक्षेप में रजिस्टर करें
• स्टोरीबोर्ड के साथ काम करें, लेकिन लाइब्रेरी स्टोरीबोर्ड संदर्भों के साथ काम कर सकती है
• एक प्रारंभिक विधि या संपत्ति के माध्यम से पंजीकरण
• एकाधिक कार्यान्वयन
• चौखटे और भागों के साथ काम करें
• थोड़ा सा सत्यापन

पुस्तकालय और क्या कर सकता है:

• 5 जीवनकाल: एकल, पेररून (.weak / .strong), perContainer (.weak / .strong), ऑब्जेक्टग्राफ, प्रोटोटाइप।
• टैग का नाम
• लॉगिंग
• चक्रीय निर्भरता के साथ काम करें
• विचारों में जड़ लें
• आस्थगित कार्यान्वयन
• तर्कों की शुरूआत, लेकिन इसकी गैर-सुरक्षा के कारण कार्यक्षमता का दस्तावेजीकरण नहीं किया गया है

योजनाओं

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

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

यह कार्यक्षमता दो भागों में बनाई गई है - पहला भाग आपको सभी जानकारी प्राप्त करने के लिए एक एपीआई जोड़ने की अनुमति देगा, और दूसरा पहले से ही विभिन्न सेवाओं के लिए एकीकरण है।

सबसे सरल विकल्प पाठ के रूप में लिंक का एक ग्राफ प्रदर्शित करना है, लेकिन मैंने पठनीय विकल्प नहीं देखा है - यदि हां, तो टिप्पणियों में विकल्प सुझाएं।

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

आपके ध्यान के लिए यह सब धन्यवाद है। मैं वास्तव में सर्वेक्षण के लिए टिप्पणियों और उत्तरों की उम्मीद करता हूं।