एक निश्चित राज्य में, "स्प्रिंगिंग" स्थिति में नहीं। यैंडेक्स रिपोर्ट

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


- सभी को मेरा नमस्कार, मेरा नाम सिरिल है। आज मैं डिपेंडेंसी इंजेक्शन के बारे में बात करूंगा।

हम अपनी रिपोर्ट के साथ शुरू करेंगे। "एक निश्चित राज्य में," स्प्रिंगिंग "राज्य में नहीं।" हम, निश्चित रूप से, वसंत के बारे में बात करेंगे, लेकिन मैं उसके अलावा सब कुछ देखना चाहता हूं। हम विशेष रूप से किस बारे में बात करेंगे?



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

मैं Yandex.Tracker टीम में काम करता हूं। हम जीरा या ट्रेलो का किराने का एनालॉग बनाते हैं। [...] हमने अपना खुद का उत्पाद बनाने का फैसला किया, जो पहले आंतरिक था। अब हम इसे बेच रहे हैं। आप में से प्रत्येक अंदर जा सकता है, अपना खुद का ट्रैकर बना सकता है और कार्य कर सकता है - उदाहरण के लिए, शैक्षिक या व्यावसायिक।

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

सामान्य तौर पर, डिपेंडेंसी इंजेक्शन क्या है? यह एक प्रोग्रामिंग पैटर्न है जो पुराने अमेरिकी कहावत को पूरा करता है, हॉलीवुड सिद्धांत: "हमें कॉल न करें, हम आपको स्वयं कॉल करेंगे।" निर्भरताएँ स्वयं हमारे पास आती हैं। यह मुख्य रूप से एक पैटर्न है, न कि एक पुस्तकालय। इसलिए, सिद्धांत रूप में, ऐसा पैटर्न लगभग हर जगह आम है। आप यह भी कह सकते हैं कि सभी अनुप्रयोग एक या दूसरे तरीके से निर्भरता इंजेक्शन का उपयोग करते हैं।



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



आइए TrackerApi के कार्यान्वयन को देखें। यहाँ, उदाहरण के लिए, हम यह कर सकते हैं: httpClient उदाहरण बनाएँ। सरल शब्दों में, हम एक ऑब्जेक्ट बनाएंगे जिसके माध्यम से हम एपीआई पर जाएंगे। इस ऑब्जेक्ट के माध्यम से हम उस पर निष्पादित विधि को कॉल करेंगे।



उदाहरण के लिए, एक कस्टम। मैंने इन वर्गों से बाहरी कोड लिखा है, और यह इसे कुछ इस तरह से उपयोग करेगा। मैं एक नया TicketCreator बनाता हूं और उस पर createTicket विधि कहता हूं।



यहां एक समस्या है - हर बार जब हम टिकट बनाते हैं, तो हम httpClient को फिर से बनाएंगे और बनाएंगे, हालांकि आम तौर पर बोलते हुए, इसके लिए कोई आवश्यकता नहीं है। httpClients बनाने के लिए बहुत गंभीर हैं।



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



हमने कोड के उपयोगकर्ताओं के लिए ज़िम्मेदारी को स्थानांतरित कर दिया है, इसलिए अब हमें एक httpClient बनाना होगा, इसे पारित करना, उदाहरण के लिए, Ticketfreator।



यह भी यहाँ बहुत अच्छा नहीं है, क्योंकि अब, इस विधि को कॉल करके, हम प्रत्येक बार फिर से httpClient बनाएंगे।



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

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



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



अब आइए यह देखने की कोशिश करें कि हमारा कोड कैसा लगेगा यदि हम इस टिकट में उसी तरह से टिप्पणी पढ़ना चाहते हैं, जैसे मेरे नीचे से। यह उसी कोड के बारे में है। हम इस टिकट पर getComments विधि को कॉल करेंगे।



वह कैसा दिखेगा? यदि हम एक टिप्पणी पाठक में इस कार्यक्षमता को लेते हैं और उसकी नकल करते हैं, तो हम httpClient के निर्माण की नकल करते हैं। यह हमें शोभा नहीं देता। हम इससे छुटकारा पाना चाहते हैं।



सब ठीक है। अब इन सभी मापदंडों को कंस्ट्रक्टर पैरामीटर के रूप में डिपेंडेंसी इंजेक्शन के रूप में आगे बढ़ाते हैं।



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

अब, आइए थोड़ा विचलन करें और देखें कि नियंत्रण का व्युत्क्रम क्या है, क्योंकि इसके साथ कई सहयोगी निर्भरता इंजेक्शन हैं।



नियंत्रण का व्युत्क्रम एक प्रोग्रामिंग सिद्धांत है जिसमें हमारे द्वारा उपयोग की जाने वाली वस्तुएं हमारे द्वारा नहीं बनाई जाती हैं। हम उनके जीवनचक्र को बिल्कुल प्रभावित नहीं करते हैं। आमतौर पर, इन ऑब्जेक्ट्स को बनाने वाली इकाई को IoC कंटेनर कहा जाता है। आपमें से कई लोगों ने यहां वसंत के बारे में सुना होगा। स्प्रिंग प्रलेखन का कहना है कि IoCs को डिपेंडेंसी इंजेक्शन के रूप में भी जाना जाता है। उनका मानना ​​है कि यह एक और एक ही है।



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



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

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

आइए वसंत पर हमारे उदाहरण को फिर से लिखने की कोशिश करें।



हम अपने TrackerApi था। मैंने यहां उपयोगकर्ता को संक्षेप में शामिल नहीं किया है। मान लीजिए कि हम httpClient के लिए करने के लिए डिपेंडेंसी इंजेक्शन में कोशिश करते हैं। ऐसा करने के लिए, हमें इसे एनोटेशन के साथ घोषित करने की आवश्यकता है। घटक , पूरे वर्ग और विशेष रूप से निर्माणकर्ता, ऑटोवेड एनोटेशन के साथ घोषित किए जाते हैं। वसंत के लिए इसका क्या मतलब है?



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



ये घटक IoC कंटेनर में गिरेंगे। हमारे लिए यह महत्वपूर्ण है कि हमारे लिए सब कुछ गिर जाए। हम केवल वही चिन्हित करते हैं जो हम घोषणा करना चाहते हैं। हमारे पास आने के लिए कुछ करने के लिए, हमें इसे कंस्ट्रक्टर में ऑटोवेड एनोटेशन का उपयोग करके घोषित करना चाहिए।



TicketCreator हम बिल्कुल उसी तरह से चिह्नित करते हैं।



और कमेंटरी भी।



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



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

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



आइए एक नज़र डालते हैं गुएस पर। यह एक पुस्तकालय है, जैसा कि मैंने कहा, दूसरे और तीसरे वसंत के बीच बनाया गया था। हमने जो सुंदरता देखी, वह नहीं थी। एक्सएमएल थे। इस समस्या को ठीक करने के लिए, और Guice द्वारा लिखा गया था। और यहां आप देख सकते हैं कि, कॉन्फ़िगरेशन के विपरीत, हम एक मॉड्यूल लिख रहे हैं। इसमें, हम स्पष्ट रूप से घोषित करते हैं कि हम इस मॉड्यूल में कौन सी कक्षाएं लगाना चाहते हैं: TrackerAPI, TrackerTicketCreator और अन्य सभी डिब्बे। बीन एनोटेशन के लिए एक एनालॉग प्रोवाइड है, जो उसी तरीके से httpClient बनाता है।



हमें इनमें से प्रत्येक सेम को घोषित करने की आवश्यकता है। हम सिंगलटन का एक उदाहरण देंगे। लेकिन विशेष रूप से, सिंगलटन कहेंगे कि इस तरह की बीन बिल्कुल एक बार बनाई जाएगी। हम इसे लगातार नहीं बनाएंगे। और Inject , क्रमशः Autowired का एक एनालॉग है।



एक छोटी सी गोली जिसका संबंध है।



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

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



यहाँ शब्दावली समान है। डैगर में गुइसे के समान ही मॉड्यूल हैं। लेकिन वे पहले से ही एनोटेशन के साथ चिह्नित हैं, न कि वर्ग से विरासत के मामले में। इसलिए, सिद्धांत बनाए रखा जाता है।

केवल माइनस यह है कि हमें हमेशा मॉड्यूल में स्पष्ट रूप से इंगित करना चाहिए कि सेम कैसे बनाई जाती है। Guice में, हम सेम के अंदर ही सेम का निर्माण दे सकते हैं। हमें यह नहीं कहना है कि हमें आगे बढ़ने के लिए किस प्रकार की निर्भरता की आवश्यकता है। और यहां हमें स्पष्ट रूप से यह कहने की आवश्यकता है।



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



यहां एक ही सारांश प्लेट के बारे में है - क्या इंजेक्ट या मॉड्यूल के मामले में बदल गया है या नहीं बदला है।



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

वह इसे कैसे करता है? कोड पीढ़ी का उपयोग करना।



यदि हम पीछे मुड़कर देखते हैं, तो हम इंटरफ़ेस घटक देखेंगे। हमने इस इंटरफ़ेस के किसी भी कार्यान्वयन को लागू नहीं किया, डैगर इसे हमारे लिए करता है। और एप्लिकेशन में इंटरफ़ेस का आगे उपयोग करना संभव होगा।



स्वाभाविक रूप से, इस गति के कारण Android दुनिया में यह बहुत आम है। निर्भरता के पेड़ को संकलन पर तुरंत जांच की जाती है, क्योंकि ऐसा कुछ भी नहीं है जिसे हम रनटाइम में स्थगित कर देंगे।

डाउनसाइड क्या हैं? उसके पास अवसर कम हैं। यह गाइस और स्प्रिंग की तुलना में अधिक वर्बोज़ है।



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

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

आगे के अध्ययन के लिए, मेरा सुझाव है कि आप इन सभी पुस्तकालयों के प्रलेखन और JSR की संरचना से खुद को परिचित करें:
- वसंत
- गिटार
- खंजर २
- JSR-330

धन्यवाद!