यूनिटी 3 डी में निर्भरता इंजेक्शन

शुभ दोपहर, प्रिय सहयोगियों!

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

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

उदाहरण

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

public class MyClass { private SpaceShip spaceShip; private KeyboardController controller; public void Init() { controller = new KeyboardController(); GameObject gameObject = GameObject.Find("/root/Ships/MySpaceShip"); spaceShip = gameObject.GetComponent<SpaceShip>(); } public void Update() { if (controller.LeftKeyPressed()) spaceShip.MoveLeft(); if (controller.RightKeyPressed()) spaceShip.MoveRight(); } } 

कोड उत्कृष्ट है - सरल और सीधा। हमारा खेल लगभग तैयार है।

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

 public class MyClass { private IControlledCharacter spaceShip; private IController controller; public void Init() { controller = new KeyboardController(); GameObject gameObject = GameObject.Find("/root/Ships/MySpaceShip"); spaceShip = gameObject.GetComponent<SpaceShip>(); } public void Update() { if (controller.LeftCmdReceived()) spaceShip.MoveLeft(); if (controller.RightCmdReceived()) spaceShip.MoveRight(); } } 

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

 public class MyClass { public IControlledCharacter SpaceShip { get; set; } public IController Controller { get; set; } public void Update() { if (Controller.LeftCmdReceived()) SpaceShip.MoveLeft(); if (Controller.RightCmdReceived()) SpaceShip.MoveRight(); } } 

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

वास्तव में ऐसा नहीं है। जिन वस्तुओं की हमें ज़रूरत है, उन्हें हमारी कक्षा के गुणों में स्वचालित रूप से स्थानांतरित किया जा सकता है - "इंजेक्ट"। यह हमारे लिए डीआई कंटेनर द्वारा किया जा सकता है!

लेकिन इसके लिए हमें उसकी थोड़ी मदद करनी होगी:
1. हमारी कक्षा की निर्भरता को स्पष्ट रूप से परिभाषित करें। उपरोक्त उदाहरण में, हम [निर्भरता] विशेषताओं के साथ गुणों का उपयोग करते हैं:

 public class MyClass { [Dependency] public IControlledCharacter SpaceShip { private get; set; } [Dependency] public IController Controller { private get; set; } public void Update() { if (Controller.LeftCmdReceived()) SpaceShip.MoveLeft(); if (Controller.RightCmdReceived()) SpaceShip.MoveRight(); } } 

2. हमें एक कंटेनर बनाना चाहिए और उसे बताना चाहिए कि इन निर्भरताओं के लिए ऑब्जेक्ट कहाँ से प्राप्त करें - इसे कॉन्फ़िगर करें:

 var container = new Container(); container.RegisterType<MyClass>(); container.RegisterType<IController, KeyboardController>(); container.RegisterSceneObject<IControlledCharacter>("/root/Ships/MySpaceShip"); 

अब कंटेनर को उस वस्तु को इकट्ठा करें जिसकी हमें आवश्यकता है:

 MyClass obj = container.Resolve<MyClass>(); 

ओब्ज में सभी आवश्यक निर्भरताएं चिपका दी जाएंगी।

यह कैसे काम करता है?

जब हम एक कंटेनर को माईक्लास प्रकार की वस्तु प्रदान करने के लिए कहते हैं तो क्या होता है?
कंटेनर पंजीकृत लोगों के बीच अनुरोधित प्रकार की खोज करता है। हमारे मामले में, MyClass वर्ग रजिस्टरटाइप () का उपयोग करके कंटेनर में पंजीकृत है, जिसका अर्थ है - अनुरोध पर, कंटेनर को इस प्रकार का एक नया ऑब्जेक्ट बनाना होगा।
एक नया MyClass ऑब्जेक्ट बनाने के बाद, कंटेनर यह देखने के लिए जांचता है कि क्या उसमें निर्भरता है? यदि कोई निर्भरता नहीं हैं, तो कंटेनर बनाई गई वस्तु को वापस कर देगा। लेकिन निर्भरता के हमारे उदाहरण में दो पूर्णांक हैं और कंटेनर उन्हें उसी तरह से हल करने की कोशिश करता है जिस तरह उपयोगकर्ता कॉल करता है <> ()।

निर्भरता में से एक एक IController प्रकार की निर्भरता है। RegisterType <IController, KeyboardController> () कंटेनर को बताता है कि IController ऑब्जेक्ट का अनुरोध करते समय, आपको प्रकार की एक नई ऑब्जेक्ट बनाने की आवश्यकता है KeyboardController (और निश्चित रूप से इसकी निर्भरता, यदि कोई हो) की अनुमति दें।
दूसरे IControlledCharacter निर्भरता के लिए ऑब्जेक्ट प्राप्त करने के लिए, हमने कंटेनर को RegisterSceneObject ("/ root / Ships / MySpaceShips") का उपयोग करके बताया। कंटेनर से कुछ भी बनाने की आवश्यकता नहीं है। यह दृश्य पेड़ में पथ के साथ खेल वस्तु को खोजने के लिए पर्याप्त है, और इसके लिए, उस घटक का चयन करें जो निर्दिष्ट इंटरफ़ेस को लागू करता है।

हमारे DI कंटेनर और क्या कर सकते हैं? ढेर सारा सामान। उदाहरण के लिए, यह सिंगलेट्स का भी समर्थन करता है। ऊपर दिए गए उदाहरण में, कोई भी जो IController का अनुरोध करता है, उसे अपने KeyboardController की एक प्रति प्राप्त होगी। हम KeyboardController को एक सिंगलटन के रूप में पंजीकृत कर सकते हैं, और फिर सभी आवेदकों को एक ही वस्तु का लिंक प्राप्त होगा। हम 'नई' का उपयोग करके वस्तु को स्वयं भी बना सकते हैं, और फिर इसे कंटेनर में स्थानांतरित कर सकते हैं ताकि यह पीड़ित को वस्तु वितरित करे। यह तब उपयोगी होता है जब किसी सिंगलटन को किसी प्रकार के नैन्टिवियल इनिशियलाइज़ेशन की आवश्यकता होती है।

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

 var controller = new Mock<IController>(); controller.Setup(c => c.LeftCmdReceived()).Returns(true); var spaceShip = new Mock<IControlledCharacter>(); var container = new Container(); container.RegisterType<MyClass>(); container.RegisterInstance<IController>(controller.Object); container.RegisterInstance<IControlledCharacter>(spaceShip.Object); var myClass = container.Resolve<MyClass>(); myClass.Update(); spaceShip.Verify(s => s.MoveLeft(), Times.Once()); spaceShip.Verify(s => s.MoveRight(), Times.Never()); 

मैंने इस टेस्ट को लिखने के लिए Moq का इस्तेमाल किया। यहाँ हम दो मोचा बनाते हैं - एक IController के लिए और दूसरा IControlledCharacter के लिए। हमने IController के लिए व्यवहार निर्धारित किया है - LeftCmdReceived () विधि को बुलाया जाने पर सही लौटना चाहिए। हम कंटेनर में दोनों मोका को पंजीकृत करते हैं। फिर हमें इसमें से MyClass ऑब्जेक्ट मिलता है (दोनों अब हमारे मोक्स होंगे) और उस पर अपडेट () कॉल करें। उसके बाद, हम सत्यापित करते हैं कि MoveLeft () विधि को एक बार बुलाया गया था, और MoveRight () - एक भी नहीं।
हां, निश्चित रूप से, मिकी MyClass "पेन" में फंस सकता है, बिना किसी कंटेनर के। हालाँकि, मैं आपको याद दिला दूं, उदाहरण विशेष रूप से सरल है। कल्पना करें कि आपको एक वर्ग का नहीं, बल्कि उन वस्तुओं का एक परीक्षण करना है, जिन्हें संयोजन में काम करना चाहिए। इस मामले में, हम केवल व्यक्तिगत संस्थाओं को मोक के साथ कंटेनर में बदल देंगे जो कि परीक्षण के लिए किसी भी तरह से उपयुक्त नहीं हैं - उदाहरण के लिए, कक्षाएं जो डेटाबेस या नेटवर्क में चढ़ती हैं।

सूखा हुआ अवशेष

1. कंटेनर की ओर मुड़ते हुए, हमें इसकी सभी निर्भरताओं के साथ पहले से ही इकट्ठी हुई वस्तु मिलती है। साथ ही उसके आश्रितों की निर्भरता, उसके आश्रितों के आश्रितों की निर्भरता आदि।
2. कक्षा निर्भरताएं कोड में बहुत स्पष्ट रूप से पहचानी जाती हैं, जो पठनीयता में सुधार करती हैं। एक नज़र यह समझने के लिए पर्याप्त है कि कौन सी संस्था वर्ग के साथ सहभागिता करती है। मेरी राय में पठनीयता, कोड का एक बहुत ही महत्वपूर्ण गुण है, यदि सबसे महत्वपूर्ण नहीं है। पढ़ने में आसान -> संशोधित करने में आसान -> बग को लागू करने की संभावना कम -> कोड लंबे समय तक रहता है -> विकास तेजी से चलता है और लागत कम होती है
3. कोड ही सरलीकृत है। यहां तक ​​कि हमारे तुच्छ उदाहरण में, हम दृश्य पेड़ में ऑब्जेक्ट खोज से छुटकारा पाने में कामयाब रहे। और वास्तविक परियोजनाओं में कोड के ऐसे ही कितने टुकड़े बिखरे हुए हैं? वर्ग अपनी मुख्य कार्यक्षमता पर अधिक केंद्रित हो गया है।
4. अतिरिक्त लचीलापन दिखाई देता है - कंटेनर सेटिंग्स बदलना आसान है। आपकी कक्षाओं को एक-दूसरे से जोड़ने के लिए जिम्मेदार सभी परिवर्तन एक ही स्थान पर स्थानीय हैं
5. इस लचीलेपन से आपकी कक्षाओं के यूनिट परीक्षण में आसानी होती है (और कनेक्टिविटी को कम करने के लिए इंटरफेस का उपयोग)
6. और आखिरी। इस जगह पर धैर्यपूर्वक पढ़ने वालों के लिए बोनस। हमें अप्रत्याशित रूप से कोड गुणवत्ता का एक अतिरिक्त मीट्रिक प्राप्त हुआ। यदि आपकी कक्षा में एन निर्भरता से अधिक है, तो इसके साथ कुछ गलत है। शायद यह अतिभारित है और यह कई वर्गों के बीच अपनी कार्यक्षमता साझा करने के लायक है। एन अपने आप को स्थानापन्न

बेशक, आपने अनुमान लगाया कि दृश्य वृक्ष में निर्भरता की खोज वही है जिसके लिए मैंने अपना डीआई कंटेनर लिखना शुरू किया। कंटेनर बहुत सरल है। आप इसके स्रोत और एक डेमो प्रोजेक्ट यहां प्राप्त कर सकते हैं: dl.dropboxusercontent.com/u/1025553/UnityDI.ar
कृपया पढ़ें और आलोचना करें।

लेख में यह भी उल्लेख किया गया है:
हल्के-आईओसी कंटेनर
Moq

पुनश्च। Github पर पोस्ट कोड: github.com/yaroslav-gurilev/UnityDI