🤜 👩‍👧‍👦 😢 C ++ में निर्भरता इंजेक्शन 💴 🌿 😏

MagicClass::getInstance().getFooFactory().createFoo().killMePlease();

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

उत्पादन

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

परीक्षण । निर्भरता इंजेक्शन के प्राथमिक लक्ष्यों में से एक। इसका तात्पर्य मुख्य कार्यान्वयन को प्रभावित किए बिना कुछ वस्तुओं को परीक्षण स्टब्स के साथ फिर से बदलने की क्षमता है।

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

परीक्षण उदाहरण के साथ एक कार्यशील संस्करण यहां से लिया जा सकता है ।

चलो व्यापार के लिए नीचे उतरो। जीवन के समय के साथ शुरू करते हैं। मैं निम्नलिखित विकल्पों का उपयोग करने में सक्षम होना चाहूंगा।

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

स्वाभाविक रूप से, क्लाइंट को यह ध्यान नहीं देना चाहिए कि एम्बेडेड ऑब्जेक्ट किस प्रकार का है।

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

 class SomeClass { public: private: inject(SomeInterface, mFieldName) };

मुझे तुरंत स्वीकार करना चाहिए कि शुरू में, निश्चित रूप से, मेरे सपनों में टेम्पलेट थे, लेकिन मैं किसी भी तरह ऊपर वर्णित कार्यान्वयन के प्रकारों का एक सरल और पारदर्शी कार्यान्वयन प्राप्त करने में विफल रहा। लेकिन सांसारिक मैक्रों के साथ यह अप्रत्याशित रूप से आसान हो गया।

परियोजना में एक जगह होनी चाहिए जहां निर्भरता निम्नानुसार कॉन्फ़िगर की गई हो।

 inject_as_share(Interface1, Class1) inject_as_singleton(Interface2, Class1) inject_as_object(Interface3, Class1) inject_as_runtime(Interface4)

पहला पैरामीटर इंटरफ़ेस है, दूसरा वह वर्ग है जो इसे लागू करता है। बेशक, एक वर्ग खुद के लिए एक इंटरफेस के रूप में कार्य कर सकता है। रनटाइम ऑब्जेक्ट के लिए, प्रोग्राम की गहराई में कहीं इनिशियलाइज़ेशन की भी आवश्यकता होगी (सबसे सफल कार्यान्वयन विकल्प नहीं, लेकिन कभी-कभी इसकी आवश्यकता भी होती है)

 inject_set_runtime(Interface4, &implementation4)

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

 inject_as_share(Interface1, Class1, "param1", 1234, true)

प्रस्तावित अवधारणा के क्रियान्वयन में देरी करने से पहले, मैं ओ 2 पर वस्तु ओ 1 की निर्भरता स्थापित करने के अन्य तरीकों पर संक्षेप में ध्यान देना चाहूंगा।

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

विन्यासक

आइए कार्यान्वयन के लिए आगे बढ़ें। आइए शुरुआत करते हैं कुंवारे लोगों से। उपयोगकर्ता के लिए, संपूर्ण सेटिंग लाइन में कम हो जाएगी

 inject_as_singleton(Interface, Class, [constructor_parameters_list])

चूंकि कंस्ट्रक्टर तर्कों की संख्या आम तौर पर अज्ञात होती है, इंजेक्शन_स_सिंगटन एक मैक्रो होता है जिसमें तर्कों की एक चर संख्या होती है। सभी प्रकार के इंजेक्शन का उपयोग समान रूप से (एक वर्ग की संपत्ति के रूप में) किया जाएगा, इसलिए शुरू में आपको एक इंटरफ़ेस के साथ आने की आवश्यकता है जो ऑब्जेक्ट्स तक पहुंच की अनुमति देगा, भले ही आप उन्हें कैसे बनाएं। हमारे मामले में, यह एक एकल प्राप्त विधि के साथ एक फैक्ट्री संरचना होगी जो किसी ऑब्जेक्ट का संदर्भ देता है जो निर्दिष्ट इंटरफ़ेस को लागू करता है।

 struct Factory { Interface& get(); };

एकल वर्ग का कार्यान्वयन क्लासिक होगा

 Interface& getInstance() { static T instance = T(...); return instance; }

निर्माता के कॉल को कुछ असामान्य (कम से कम मेरे लिए) फ़ॉर्म में लिखा जाना था, क्योंकि विकल्प

 static T instance(...);

मापदंडों के बिना एक कंस्ट्रक्टर के मामले में, कंपाइलर इसे फ़ंक्शन घोषणा के रूप में स्पष्ट रूप से व्याख्या करता है।

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

 #define inject_as_singleton(Interface, T, ...) \ namespace injector##Interface{ \ Interface& getInstance() \ { \ static T instance = T(__VA_ARGS__); \ return instance; \ } \ struct Factory \ { \ Interface& get() { return getInstance(); } \ }; \ }

मैंने आगे कदम-दर-चरण पेंट नहीं किया, लेकिन दृष्टिकोण हमेशा समान है - जीवनकाल + निश्चित फ़ैक्टरी इंटरफ़ेस संरचना के प्रबंधन के लिए "यह कैसे काम करता है" रणनीति का कार्यान्वयन और एक अलग नामस्थान में यह सब।

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

 #define inject_as_share(Interface, T, ...) \ namespace injector##Interface{ \ struct Factory \ { \ Factory() { \ if (refCount == 0) { \ object = new T(__VA_ARGS__); \ } \ ++refCount; \ } \ ~Factory() { \ if (--refCount == 0) { \ delete object; \ } \ } \ Interface& get() { return *object; } \ static T* object; \ static unsigned int refCount; \ }; \ T* Factory::object = 0; \ unsigned int Factory::refCount = 0; \ }

कोड को विशेष स्पष्टीकरण की आवश्यकता नहीं है - हम कंस्ट्रक्टर में काउंटर बढ़ाते हैं, कार्यान्वित वर्ग का एक उदाहरण बनाते हैं यदि आवश्यक हो, तो विध्वंसक में काउंटर को कम करें और यदि एक घंटे बीत चुका है, तो अनावश्यक वस्तु को हटा दें।

एक कारखाने के क्षेत्र के रूप में "प्रत्येक ग्राहक के लिए स्वयं की वस्तु" का कार्यान्वयन काफी सरलता से लागू किया जाता है।

 #define inject_as_object(Interface, T, ...) \ namespace injector##Interface{ \ struct Factory \ { \ Factory() : object(__VA_ARGS__) {} \ Interface& get() { return object; } \ T object; \ }; \ }

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

 #define inject_as_runtime(Interface) \ namespace injector##Interface{ \ struct Factory \ { \ Interface& get() { return *object; } \ static Interface* object; \ }; \ Interface* Factory::object = 0; \ }

रणनीति के अंतिम कार्यान्वयन के लिए, आपको ऑब्जेक्ट सेट करने के लिए एक विशेष मैक्रो की आवश्यकता होगी

 #define inject_set_runtime(Interface, Value) injector##Interface::Factory::object = (Value);

की शुरूआत

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

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

तो, मैक्रो एम्बेड करने वाली संपत्ति इस तरह दिखाई देगी

 #define inject(Interface, Name) \ struct Interface##Proxy \ { \ Interface* operator->() \ { \ return &factory.get(); \ } \ injector##Interface::Factory factory; \ }; \ Interface##Proxy Name;

बस एक आवरण वर्ग जो वांछित कारखाने का मालिक है और इसे ऑपरेटर -> में एक्सेस करता है

उदाहरण

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

 class IWork { public: virtual void doSmth() = 0; virtual ~IWork() {}; };

और कई कक्षाएं वर्क 1, वर्क 2, आदि, इसे लागू करते हुए, इन वर्गों में से कुछ के पास पैरामीटर हैं (उदाहरण के पूर्ण पाठ यहां हैं )। सबसे पहले, कॉन्फ़िगर करें

 inject_as_share(IWork, Work1) inject_as_singleton(Work2, Work2, 1) inject_as_object(Work3, Work3, 1, true) inject_as_runtime(Work4)

फिर हम प्रयोगों के लिए एक वर्ग बनाते हैं

 class Employee { public: void doIt() { mWork1->doSmth(); mWork2->doSmth(); mWork3->doSmth(); mWork4->doSmth(); } private: inject(IWork, mWork1) inject(Work2, mWork2) inject(Work3, mWork3) inject(Work4, mWork4) };

और उपयोग करें

 Work4 w4; inject_set_runtime(Work4, &w4) Employee e1; e1.doIt();

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

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

C ++ में निर्भरता इंजेक्शन

उत्पादन

विन्यासक

की शुरूआत

उदाहरण

More articles: