निर्भरता इंजेक्शन (DI) क्या है?
जैसा कि अन्य लोगों ने कहा है, डिपेंडेंसी इंजेक्शन (डीआई) प्रत्यक्ष निर्माण की ज़िम्मेदारी को हटाता है, और जीवन का प्रबंधन, अन्य ऑब्जेक्ट इंस्टेंस का, जिस पर हमारी रुचि का वर्ग (उपभोक्ता वर्ग) निर्भर है ( यूएमएल अर्थ में )। इन उदाहरणों को इसके बजाय हमारे उपभोक्ता वर्ग को दिया जाता है, आमतौर पर कंस्ट्रक्टर मापदंडों के रूप में या संपत्ति बसने वालों के माध्यम से (उपभोक्ता वर्ग के लिए निर्भरता वस्तु इंस्टेंसेसिंग और पासिंग का प्रबंधन आमतौर पर नियंत्रण के उलट (IoC) कंटेनर द्वारा किया जाता है , लेकिन यह एक और विषय है) ।
DI, DIP और SOLID
विशेष रूप से, रॉबर्ट सी मार्टिन के प्रतिमान में उन्मुखी डिजाइन वस्तु की ठोस सिद्धांतों , DIके संभावित कार्यान्वयन में से एक है निर्भरता उलट सिद्धांत (DIP) । DIP है Dकी SOLIDमंत्र अन्य DIP कार्यान्वयन सेवा लोकेटर, और प्लगइन पैटर्न में शामिल हैं -।
डीआईपी का उद्देश्य कक्षाओं के बीच तंग, ठोस निर्भरता को कम करना है, और इसके बजाय, एक अमूर्त के माध्यम से युग्मन को ढीला करना है, जिसे भाषा और दृष्टिकोण के आधार पर interface, abstract classया pure virtual class, के माध्यम से प्राप्त किया जा सकता है ।
डीआईपी के बिना, हमारा कोड (मैंने इसे 'उपभोग करने वाला वर्ग' कहा है) सीधे एक ठोस निर्भरता से जुड़ा होता है और अक्सर यह जानने की जिम्मेदारी के साथ बोझ भी होता है, और इस निर्भरता का एक उदाहरण, अर्थात् प्रबंधन, प्रबंधन करना।
"I need to create/use a Foo and invoke method `GetBar()`"
जबकि डीआईपी के आवेदन के बाद, आवश्यकता को ढीला Fooकर दिया गया है , और निर्भरता के जीवनकाल को प्राप्त करने और प्रबंधित करने की चिंता को हटा दिया गया है:
"I need to invoke something which offers `GetBar()`"
DIP (और DI) का उपयोग क्यों करें?
इस तरह से वर्गों के बीच निर्भरता घटाना अन्य निर्भरता के साथ इन निर्भरता वर्गों के आसान प्रतिस्थापन की अनुमति देता है जो अमूर्तता के पूर्वापेक्षाओं को भी पूरा करते हैं (उदाहरण के लिए निर्भरता को उसी इंटरफ़ेस के अन्य कार्यान्वयन के साथ स्विच किया जा सकता है)। इसके अलावा, जैसा कि दूसरों ने उल्लेख किया है, संभवतः डीआईपी के माध्यम से कक्षाओं को डिकॉप करने का सबसे आम कारण एक उपभोग वर्ग को अलगाव में परीक्षण करने की अनुमति देना है, क्योंकि ये समान निर्भरता अब ठूंठ और / या नकली हो सकती हैं।
डीआई का एक परिणाम यह है कि निर्भरता वस्तु उदाहरणों का जीवन प्रबंधन अब एक उपभोग वर्ग द्वारा नियंत्रित नहीं किया जाता है, क्योंकि निर्भरता वस्तु अब उपभोग वर्ग (कंस्ट्रक्टर या सेटर इंजेक्शन के माध्यम से) में प्रवेश कर जाती है।
इसे विभिन्न तरीकों से देखा जा सकता है:
- यदि उपभोग करने वाले वर्ग द्वारा निर्भरता के जीवन पर नियंत्रण को बनाए रखने की आवश्यकता है, तो उपभोक्ता वर्ग में निर्भरता वर्ग के उदाहरणों को बनाने के लिए (अमूर्त) कारखाने को इंजेक्ट करके नियंत्रण फिर से स्थापित किया जा सकता है। उपभोक्ता
Createआवश्यकता के अनुसार कारखाने के माध्यम से इंस्टेंसेस प्राप्त करने में सक्षम हो जाएगा , और एक बार पूरा होने पर इन इंस्टेंस का निपटान करेगा।
- या, निर्भरता के उदाहरणों के जीवनकाल नियंत्रण को आईओसी कंटेनर (इसके बारे में अधिक जानकारी) से संबंधित किया जा सकता है।
कब करें DI का इस्तेमाल?
- जहां एक समान कार्यान्वयन के लिए आश्रित को स्थानापन्न करने की आवश्यकता होगी,
- किसी भी समय जहां आपको अपनी निर्भरता के अलगाव में एक वर्ग के तरीकों का परीक्षण करने की आवश्यकता होगी,
- जहां एक निर्भरता के जीवनकाल की अनिश्चितता वारंट प्रयोग हो सकती है (जैसे अरे,
MyDepClassधागा सुरक्षित है - क्या होगा अगर हम इसे एक सिंगलटन बनाते हैं और सभी उपभोक्ताओं में एक ही उदाहरण इंजेक्ट करते हैं?)
उदाहरण
यहाँ एक सरल C # कार्यान्वयन है। नीचे दिए गए उपभोक्ता वर्ग को देखते हुए:
public class MyLogger
{
public void LogRecord(string somethingToLog)
{
Console.WriteLine("{0:HH:mm:ss} - {1}", DateTime.Now, somethingToLog);
}
}
हालाँकि सहज रूप से, यह staticदो अन्य वर्गों पर निर्भरता है, System.DateTimeऔर System.Console, जो न केवल लॉगिंग आउटपुट विकल्पों को सीमित करता है (कंसोल पर लॉगिंग बेकार होगा यदि कोई नहीं देख रहा है), लेकिन इससे भी बदतर, यह निर्भरता को देखते हुए स्वचालित रूप से परीक्षण करना मुश्किल है एक गैर-नियतात्मक प्रणाली घड़ी।
हालाँकि हम DIPइस वर्ग पर लागू कर सकते हैं , एक निर्भरता के रूप में टाइमस्टैम्पिंग की चिंता को समाप्त करके, MyLoggerकेवल एक सरल इंटरफ़ेस के लिए युग्मन :
public interface IClock
{
DateTime Now { get; }
}
हम Consoleएब्स्ट्रैक्शन पर निर्भरता को भी ढीला कर सकते हैं , जैसे कि ए TextWriter। निर्भरता इंजेक्शन आमतौर पर या तो constructorइंजेक्शन के रूप में लागू किया जाता है (एक सेवन वर्ग के निर्माता के लिए एक पैरामीटर के रूप में एक निर्भरता के लिए एक अमूर्त पासिंग) या Setter Injection(एक setXyz()सेटर या निर्भरता के साथ निर्भरता गुजर रहा है {set;}। परिभाषित संपत्ति के साथ संपत्ति )। कंस्ट्रक्टर इंजेक्शन को प्राथमिकता दी जाती है, क्योंकि यह गारंटी देता है कि निर्माण के बाद वर्ग एक सही स्थिति में होगा, और आंतरिक निर्भरता क्षेत्रों को readonly(C #) या final(जावा) के रूप में चिह्नित करने की अनुमति देता है । इसलिए उपरोक्त उदाहरण पर कंस्ट्रक्टर इंजेक्शन का उपयोग करना, यह हमें छोड़ देता है:
public class MyLogger : ILogger // Others will depend on our logger.
{
private readonly TextWriter _output;
private readonly IClock _clock;
// Dependencies are injected through the constructor
public MyLogger(TextWriter stream, IClock clock)
{
_output = stream;
_clock = clock;
}
public void LogRecord(string somethingToLog)
{
// We can now use our dependencies through the abstraction
// and without knowledge of the lifespans of the dependencies
_output.Write("{0:yyyy-MM-dd HH:mm:ss} - {1}", _clock.Now, somethingToLog);
}
}
(एक ठोस Clockप्रदान करने की आवश्यकता है, जो निश्चित रूप से वापस लौट सकता है DateTime.Nowऔर दो आश्रितों को आईओसी कंटेनर द्वारा कंस्ट्रक्टर इंजेक्शन प्रदान करने की आवश्यकता है)
एक स्वचालित यूनिट टेस्ट बनाया जा सकता है, जो निश्चित रूप से यह साबित करता है कि हमारा लकड़हारा सही ढंग से काम कर रहा है, क्योंकि अब हम निर्भरता पर नियंत्रण रखते हैं - समय, और हम लिखित आउटपुट पर जासूसी कर सकते हैं:
[Test]
public void LoggingMustRecordAllInformationAndStampTheTime()
{
// Arrange
var mockClock = new Mock<IClock>();
mockClock.Setup(c => c.Now).Returns(new DateTime(2015, 4, 11, 12, 31, 45));
var fakeConsole = new StringWriter();
// Act
new MyLogger(fakeConsole, mockClock.Object)
.LogRecord("Foo");
// Assert
Assert.AreEqual("2015-04-11 12:31:45 - Foo", fakeConsole.ToString());
}
अगला कदम
डिपेंडेंसी इंजेक्शन आमतौर पर कंक्रीट डिपेंडेंसी इंस्टेंस को इंजेक्ट करने (प्रदान करने) और जीवन काल के उदाहरणों को प्रबंधित करने के लिए कंट्रोल कंटेनर (IoC) के व्युत्क्रम से जुड़ा होता है । कॉन्फ़िगरेशन / बूटस्ट्रैपिंग प्रक्रिया के दौरान, IoCकंटेनर निम्नलिखित को परिभाषित करने की अनुमति देते हैं:
- प्रत्येक अमूर्त और कॉन्फ़िगर किए गए कंक्रीट कार्यान्वयन के बीच मानचित्रण (उदाहरण के लिए "किसी भी समय उपभोक्ता किसी से अनुरोध करता है
IBar, ConcreteBarउदाहरण के लिए वापस लौटें " )
- नीतियों को प्रत्येक निर्भरता के जीवन प्रबंधन के लिए स्थापित किया जा सकता है, उदाहरण के लिए, प्रत्येक उपभोक्ता उदाहरण के लिए एक नई वस्तु बनाने के लिए, सभी उपभोक्ताओं के बीच एक सिंगलटन निर्भरता उदाहरण साझा करने के लिए, एक ही निर्भरता उदाहरण को एक ही धागे में साझा करने के लिए, आदि।
- .Net में, IoC कंटेनर प्रोटोकॉल के बारे में जानते हैं जैसे कि
IDisposableऔर Disposingकॉन्फ़िगर जीवन प्रबंधन के अनुरूप निर्भरता की जिम्मेदारी लेंगे ।
आमतौर पर, एक बार IoC कंटेनरों को कॉन्फ़िगर / बूटस्ट्रैप किया गया है, वे पृष्ठभूमि में मूल रूप से काम करते हैं, जिससे कोडर निर्भरता के बारे में चिंता करने के बजाय कोड पर ध्यान केंद्रित करने की अनुमति देता है।
DI- अनुकूल कोड की कुंजी वर्गों के स्थिर युग्मन से बचना है, और निर्भरता के निर्माण के लिए नए () का उपयोग नहीं करना है
उदाहरण के अनुसार, निर्भरता के विघटन के लिए कुछ डिज़ाइन प्रयास की आवश्यकता होती है, और डेवलपर के लिए, newसीधे निर्भरता की आदत को तोड़ने के लिए एक प्रतिमान बदलाव की आवश्यकता होती है , और इसके बजाय निर्भरता को प्रबंधित करने के लिए कंटेनर पर भरोसा करना चाहिए।
लेकिन लाभ कई हैं, विशेष रूप से आपकी रुचि के वर्ग का पूरी तरह से परीक्षण करने की क्षमता में।
नोट : new ..()POCO / POJO / Serialization DTOs / Entity रेखांकन / बेनामी JSON अनुमानों एट अल - अर्थात "डेटा केवल" वर्ग या रिकॉर्ड - निर्माण या उपयोग किए गए तरीकों से निर्मित / मैपिंग / प्रोजेक्शन (प्रक्षेपण ) को निर्भरता के रूप में नहीं माना जाता है। यूएमएल भावना) और डीआई के अधीन नहीं। newइनका उपयोग करना ठीक है।
