👨🏾‍🚒 👨‍⚖️ 👍🏼 Zenject: कैसे एक IoC कंटेनर आपकी परियोजना पर निर्भरता इंजेक्शन को मार सकता है 🦌 👇🏽 🌇

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

इसमें किसकी दिलचस्पी हो सकती है?

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

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

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

परिचय

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

मैंने 3 बड़ी यूनिटी परियोजनाओं में ज़ेनजेक्ट का उपयोग किया, और बड़ी संख्या में डेवलपर्स के साथ भी संवाद किया जिन्होंने इसका उपयोग किया। इस लेख को लिखने का कारण अक्सर पूछे जाने वाले प्रश्न हैं:

क्या Zenject एक अच्छा समाधान है?
ज़ेनजेक्ट में क्या गड़बड़ है?
Zenject का उपयोग करते समय क्या कठिनाइयाँ आती हैं?

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

आइए देखें कि डेवलपर्स के पास ऐसे प्रश्न और समस्याएं क्यों हैं। आप निम्नानुसार उत्तर दे सकते हैं:

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

यह ध्यान देने योग्य है कि कंटेनर के उचित और सीमित उपयोग के साथ, अनुप्रयोग में किसी अन्य कंटेनर का उपयोग करने के लिए स्विच करना (या " गरीबों के लिए कार्यान्वयन " के पक्ष में कंटेनर का उपयोग करने से इनकार करना) काफी संभव है और इसमें अधिक समय नहीं लगेगा। सच है, ऐसी स्थिति में, यह संभावना नहीं है कि आपको इसकी आवश्यकता होगी।

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

पहला पहलू DI कंटेनरों का उद्देश्य है। मार्क सिमन इस विषय पर अपनी पुस्तक में निम्नलिखित लिखते हैं:

डीआई कंटेनर एक सॉफ्टवेयर लाइब्रेरी है जो वस्तुओं को इकट्ठा करने और उनके जीवन चक्र को प्रबंधित करते समय किए जाने वाले कई कार्यों को स्वचालित कर सकता है।

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

दूसरा पहलू DI पैटर्न है । मार्क सिमन चार मुख्य पैटर्न की पहचान करता है, आवृत्ति द्वारा क्रमबद्ध और उनके उपयोग की आवश्यकता:

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

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

खतरनाक कार्यक्षमता।

गुणों को लागू करें

यह कंस्ट्रक्टर के कार्यान्वयन के बाद दूसरा सबसे आम DI पैटर्न है, लेकिन इसका उपयोग अक्सर कम किया जाता है। ज़ेनजेक्ट में लागू निम्नानुसार है:

public class Foo { [Inject] public IBar Bar { get; private set; } }

इसके अलावा, ज़ेनजेक्ट में "फील्ड इंजेक्शन" जैसी अवधारणा भी है। आइए देखें कि सभी ज़ेनजेक्ट में यह कार्यक्षमता सबसे खतरनाक क्यों है।

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

कारखानों (और मेमोरीपूल)

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

 public class Enemy { DiContainer Container; public Enemy(DiContainer container) { Container = container; } public void Update() { ... var player = Container.Resolve<Player>(); WalkTowards(player.Position); ... etc. } }

पहले से ही इस उदाहरण में डीआई का घोर उल्लंघन है। लेकिन यह एक उदाहरण है कि पूरी तरह से कस्टम कारखाना कैसे बनाया जाए। यहाँ मुख्य समस्या क्या है?

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

आइए देखें कि ज़ेनजेक्ट के "बिल्ट-इन" कारखाने कैसे काम करते हैं। इसके लिए एक इफैक्टीव इंटरफ़ेस है, जिसे लागू करने से हम प्लेसहोल्डरफैक्ट्री क्लास में चले जाते हैं:

  public abstract class PlaceholderFactory<TValue> : IPlaceholderFactory { [Inject] void Construct(IProvider provider, InjectContext injectContext)

इसमें हम InjectContext पैरामीटर देखते हैं जिसके कई निर्माता हैं, प्रपत्र:

  public InjectContext(DiContainer container, Type memberType) : this() { Container = container; MemberType = memberType; }

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

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

विधि कार्यान्वयन

ज़ेनजेक्ट में विधि के कार्यान्वयन का तर्क इस प्रकार है: पहले, सभी वर्गों में, कंस्ट्रक्टर को लागू किया जाता है, फिर गुणों को लागू किया जाता है, और अंत में विधि को लागू किया जाता है। प्रलेखन में दिए गए कार्यान्वयन के उदाहरण पर विचार करें:

 public class Foo { [Inject] public Init(IBar bar, Qux qux) { _bar = bar; _qux = qux; } }

यहाँ क्या नुकसान हैं:

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

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

ग्लोबल बाइंडिंग

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

पहचानकर्ता

एक वर्ग में समान निर्भरता के एक सेट से एक निश्चित निर्भरता प्राप्त करने के लिए एक पहचानकर्ता के लिए एक विशिष्ट बाध्यकारी सेट करने की क्षमता। एक उदाहरण:

 Container.Bind<IFoo>().WithId("foo").To<Foo1>().AsSingle(); Container.Bind<IFoo>().To<Foo2>().AsSingle(); public class Bar1 { [Inject(Id = "foo")] IFoo _foo; } public class Bar2 { [Inject] IFoo _foo; }

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

सिग्नल और ITickable

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

ITickable इंटरफ़ेस के लिए समर्थन - मानक विधियों को प्रतिस्थापित करना, कंटेनर में ITickable इंटरफ़ेस के साथ ऑब्जेक्ट को अपडेट करने के तरीकों को कॉल डेलिगेट करके Unity में अपडेट, लेटअप और फिक्स्डअपडेट। एक उदाहरण प्रलेखन में भी है, और लेख के संदर्भ में इसका कार्यान्वयन भी कोई फर्क नहीं पड़ता है।

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

आउटपुट के बजाय

कंटेनरों के बारे में सबसे महत्वपूर्ण बात यह समझना है कि डीआई का उपयोग डीआई कंटेनर के उपयोग से स्वतंत्र है। एक एप्लिकेशन कई शिथिल युग्मित वर्गों और मॉड्यूल से बनाया जा सकता है, और इनमें से किसी भी मॉड्यूल को कंटेनर के बारे में कुछ भी पता नहीं होना चाहिए।

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

Zenject: कैसे एक IoC कंटेनर आपकी परियोजना पर निर्भरता इंजेक्शन को मार सकता है