🤲 🦋 🅾️ सभी समान, आप ऐसा नहीं कर सकते! - लंबी अवधि के डिजाइन के लिए इंटरफेस और निर्भरता इंजेक्शन का उपयोग करना 🕉️ ▫️ 👲🏽

सभी को नमस्कार!

अंत में हमारे पास मार्क सिमन की पुस्तक " .NET में निर्भरता इंजेक्शन " को अपडेट करने का अनुबंध है - मुख्य बात यह है कि वह इसे जल्द से जल्द समाप्त कर दे। हमारे पास वसंत 5 में डिजाइन पैटर्न के बारे में डिजाइन में सम्मानित दिनेश राजपूत की एक पुस्तक भी है, जिसमें से एक अध्याय भी निर्भरता के कार्यान्वयन के लिए समर्पित है।

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

मूल का भावनात्मक रंग थोड़ा शांत है, अनुवाद में विस्मयादिबोधक बिंदुओं की संख्या कम हो जाती है। अच्छा पढ़ लो!

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

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

इंटरफेस

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

prog.go:22:85: cannot use BadPricer literal (type BadPricer) as type StockPricer in argument to isPricerHigherThan100: BadPricer does not implement StockPricer (missing CurrentPrice method) Program exited.

इंटरफेस एक उपकरण है जो कॉल करने वाले को कैली से अलग करने में मदद करता है, यह एक अनुबंध का उपयोग करके किया जाता है।

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

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

Action भी सीधे HTTP पर निर्भर है। इस प्रकार, दोनों राज्यों को पूरी तरह से समझना चाहिए कि एक्सचेंज डेटा और / या पूर्ण लेनदेन निकालने के लिए HTTP का उपयोग कैसे करें।

यहां यह बताया जा सकता है कि कार्यान्वयन क्या हो सकता है:

 func analyze(ticker string, maxTradePrice float64) (bool, err) { resp, err := http.Get( "http://stock-service.com/currentprice/" + ticker ) if err != nil { //   } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) // ... currentPrice := parsePriceFromBody(body) var hasTraded bool var err error if currentPrice <= maximumTradePrice { err = doTrade(ticker, currentPrice) if err == nil { hasTraded = true } } return hasTraded, err }

यहां, कॉलर ( analyze ) सीधे HTTP पर निर्भर है। उसे यह जानना आवश्यक है कि HTTP अनुरोध कैसे तैयार किए जाते हैं। उनकी पार्सिंग कैसे की जाती है। रिट्रीट, टाइमआउट, प्रमाणीकरण आदि को कैसे संभालना है। http पर उसकी करीबी पकड़ है। जब भी हम विश्लेषण कहते हैं, तो हमें http लाइब्रेरी को भी कॉल करना चाहिए ।

इंटरफ़ेस यहाँ हमारी मदद कैसे कर सकता है? इंटरफ़ेस द्वारा प्रदान किए गए अनुबंध में, आप विशिष्ट कार्यान्वयन के बजाय व्यवहार का वर्णन कर सकते हैं।

 type StockExchange interface { CurrentPrice(ticker string) float64 }

उपरोक्त StockExchange की अवधारणा को परिभाषित करता है। यह यहाँ कहता है कि StockExchange केवल StockExchange को कॉल करने का समर्थन करता है। ये तीन पंक्तियाँ मुझे सभी की सबसे शक्तिशाली वास्तुकला तकनीक लगती हैं। वे हमें आवेदन पर निर्भरता को बहुत अधिक आत्मविश्वास से नियंत्रित करने में मदद करते हैं। परीक्षण प्रदान करें। एक्स्टेंसिबिलिटी प्रदान करें।

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

इंटरफेस के मूल्य को पूरी तरह से समझने के लिए, आपको "निर्भरता इंजेक्शन" नामक तकनीक को मास्टर करने की आवश्यकता है।

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

यदि हमने HTTP अनुरोध को इंटरफ़ेस के पीछे रखा है, तो कॉल करने वाले को अलग किया जा सकता है, और उसे "पता नहीं" होगा कि HTTP अनुरोध वास्तव में हुआ था।

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

 func analyze(se StockExchange, ticker string, maxTradePrice float64) (bool, error) { currentPrice := se.CurrentPrice(ticker) var hasTraded bool var err error if currentPrice <= maximumTradePrice { err = doTrade(ticker, currentPrice) if err == nil { hasTraded = true } } return hasTraded, err }

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

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

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

चूंकि प्रोग्राम के टुकड़े (जो इंटरफेस पर निर्भर करते हैं) को विशिष्ट कार्यान्वयन को बदलते / जोड़ते / हटाते समय बदलने की आवश्यकता नहीं होती है, ऐसा डिजाइन टिकाऊ हो जाता है । मान लीजिए कि हम पाते हैं कि StockService बहुत बार अनुपलब्ध है।

उपरोक्त उदाहरण कैसे एक फ़ंक्शन को कॉल करने से अलग है? फ़ंक्शन कॉल लागू करते समय, कार्यान्वयन भी क्लीनर हो जाएगा। अंतर यह है कि जब आप फ़ंक्शन को कॉल करते हैं, तो हमें अभी भी HTTP का सहारा लेना पड़ता है। analyze विधि केवल फ़ंक्शन के कार्य को सौंपेगी, जिसे http को कॉल करना चाहिए, बजाय सीधे http को कॉल करने के। इस तकनीक की पूरी ताकत "इंजेक्शन" में निहित है, अर्थात, इसमें कॉल करने वाला व्यक्ति कैली को इंटरफ़ेस प्रदान करता है। यह वास्तव में निर्भरता उलटा कैसे होता है, जहां कीमतें केवल इंटरफ़ेस पर निर्भर करती हैं, और कार्यान्वयन पर नहीं।

बॉक्स कार्यान्वयन से बाहर कई

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

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

उत्पादन

मूल HTTP कार्यान्वयन पहले से ही प्राथमिक analyze कार्यान्वयन में मौजूद है; हमारे लिए जो कुछ भी है वह इसे निकालना है और इंटरफ़ेस के एक ठोस कार्यान्वयन के पीछे इसे संक्षिप्त करना है।

 type HTTPStockExchange struct {} func (se HTTPStockExchange) CurrentPrice(ticker string) float64 { resp, err := http.Get( "http://stock-service.com/currentprice/" + ticker ) if err != nil { //   } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) // ... return parsePriceFromBody(body) }

कोड जिसे हमने पहले विश्लेषण फ़ंक्शन से जोड़ा था, अब स्वायत्त है और StockExchange इंटरफ़ेस को संतुष्ट करता है, यानी अब हम इसे analyze करने के लिए पास कर सकते हैं। जैसा कि आप उपरोक्त आरेखों से याद करते हैं, विश्लेषण अब HTTP निर्भरता से जुड़ा नहीं है। इंटरफ़ेस का उपयोग करते हुए, analyze करता है कि "कल्पना" न करें कि पर्दे के पीछे क्या होता है। वह केवल यह जानता है कि उसे एक ऐसी वस्तु दिए जाने की गारंटी दी जाएगी जिसके साथ वह CurrentPrice को कॉल कर सकता है।

यहाँ भी हम इनकैप्सुलेशन के विशिष्ट गुणों का लाभ उठाते हैं। पहले, जब http- अनुरोधों को विश्लेषण के लिए बांधा गया था, http के माध्यम से एक्सचेंज के साथ संवाद करने का एकमात्र तरीका अप्रत्यक्ष था - analyze पद्धति के माध्यम से। हां, हम इन कॉल्स को फंक्शंस में इनकैप कर सकते हैं और फंक्शन को स्वतंत्र रूप से निष्पादित कर सकते हैं, लेकिन इंटरफेस हमें कॉलर से अलग करने के लिए बाध्य करते हैं। अब हम कॉल करने वाले की परवाह किए बिना HTTPStockExchange परीक्षण कर सकते हैं। यह मौलिक रूप से हमारे परीक्षणों के दायरे को प्रभावित करता है और हम परीक्षण विफलताओं को कैसे समझते हैं और इसका जवाब देते हैं।

परीक्षण

मौजूदा कोड में, हमारे पास HTTPStockService संरचना है, जो हमें अलग से यह सुनिश्चित करने की अनुमति देती है कि यह विनिमय सेवा के साथ संवाद कर सके और इससे प्राप्त प्रतिक्रियाओं को पार्स कर सके। लेकिन अब यह सुनिश्चित करें कि विश्लेषण StockExchange इंटरफ़ेस से प्रतिक्रिया को सही ढंग से संभाल सकता है, इसके अलावा, यह ऑपरेशन विश्वसनीय और प्रतिलिपि प्रस्तुत करने योग्य है।

 currentPrice := se.CurrentPrice(ticker) if currentPrice <= maxTradePrice { err := doTrade(ticker, currentPrice) }

WE COULD HTTP के साथ कार्यान्वयन का उपयोग करता है, लेकिन इसके कई नुकसान होंगे। इकाई परीक्षण में नेटवर्क कॉल करना धीमा हो सकता है, खासकर बाहरी सेवाओं के लिए। देरी और एक अस्थिर नेटवर्क कनेक्शन के कारण, परीक्षण अविश्वसनीय हो सकते हैं। इसके अलावा, अगर हमें इस कथन के साथ परीक्षणों की आवश्यकता है कि हम लेन-देन को पूरा कर सकते हैं, और इस कथन के साथ परीक्षण करते हैं कि हम उन मामलों को फ़िल्टर कर सकते हैं जिनमें लेनदेन का निष्कर्ष नहीं निकाला जाना चाहिए, तो वास्तविक उत्पादन डेटा को खोजना मुश्किल होगा जो इन दोनों को संतुष्ट करता है स्थिति। कोई भी maxTradePrice चुन सकता है, इस तरह से प्रत्येक स्थिति का कृत्रिम रूप से अनुकरण कर सकता है, उदाहरण के लिए, maxTradePrice := -100 लेन-देन पूरा नहीं होना चाहिए, और maxTradePrice := 10000000 जाहिर तौर पर लेनदेन के साथ समाप्त हो सकता है।

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

एक बेहतर तरीका है, और इसमें इंटरफेस का उपयोग करना शामिल है!

एक इंटरफ़ेस होने से, आप StockExchange कार्यान्वयन का सावधानीपूर्वक निर्माण कर सकते हैं, जो हमें जल्दी, सुरक्षित और मज़बूती से analyze करने की अनुमति देगा।

 type StubExchange struct { Price float64 } func (se StubExchange) CurrentPrice(ticker string) float64 { return se.Price } func TestAnalyze_MakeTrade(t *testing.T) { se := StubExchange{Price: 10} maxTradePrice := 11 traded, err := analyze(se, "TSLA", maxTradePrice) if err != nil { t.Errorf("expected err == nil received: %s", err) } if !traded { t.Error("expected traded == true") } } func TestAnalyze_DontTrade(t *testing.T) { se := StubExchange{Price: 10} maxTradePrice := 9 traded, err := analyze(se, "TSLA", maxTradePrice) //  }

विनिमय सेवा का स्टब ऊपर उपयोग किया जाता है, धन्यवाद जिसके लिए analyze में हमारे लिए ब्याज की शाखा लॉन्च की गई है। फिर, प्रत्येक परीक्षण में यह सुनिश्चित करने के लिए बयान दिए जाते हैं कि विश्लेषण वही करता है जिसकी आवश्यकता है। यद्यपि यह एक परीक्षण कार्यक्रम है, मेरा अनुभव बताता है कि घटक / वास्तुकला, जहां इंटरफेस लगभग इस तरह से उपयोग किए जाते हैं, युद्ध के कोड में स्थायित्व के लिए इस तरह से परीक्षण किए जाते हैं !!! इंटरफेस के लिए धन्यवाद, हम मेमोरी में नियंत्रित StockExchange उपयोग कर सकते हैं, जो विश्वसनीय, आसानी से कॉन्फ़िगर करने योग्य, समझने में आसान, प्रतिलिपि प्रस्तुत करने योग्य, बिजली से तेज़ परीक्षण !!!

अनपिन - कॉलर कॉन्फ़िगरेशन

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

यह वह जगह है जहां निर्भरता का कार्यान्वयन काम में आता है।

 func main() { var ticker = flag.String("ticker", "", "stock ticker symbol to trade for") var maxTradePrice = flag.Float64("maxtradeprice", "", "max price to pay for a share of the ticker symbol." se := HTTPStockExchange{} analyze(se, *ticker, *maxTradePrice) }

हमारे परीक्षण मामले की तरह, स्टॉकएक्सचेंज का विशिष्ट कंक्रीट कार्यान्वयन जो analyze साथ उपयोग किया जाएगा, विश्लेषण के बाहर कॉलर द्वारा कॉन्फ़िगर किया गया है। फिर analyze करने के लिए इसे (इंजेक्शन) पास किया जाता है। यह सुनिश्चित करता है कि HTTPStockExchange कैसे कॉन्फ़िगर किया गया HTTPStockExchange इसके बारे में NOTHING का विश्लेषण किया जाता HTTPStockExchange । शायद हम http डोमेन प्रदान करना चाहते हैं जिसे हम कमांड लाइन ध्वज के रूप में उपयोग करने जा रहे हैं, और फिर विश्लेषण को बदलना नहीं होगा। या क्या करें यदि हमें HTTPStockExchange का उपयोग करने के लिए किसी तरह का प्रमाणीकरण या टोकन प्रदान करने की आवश्यकता होगी, जिसे पर्यावरण से निकाला जाएगा? फिर से, विश्लेषण को बदलना नहीं चाहिए।

कॉन्फ़िगरेशन analyze बाहर के स्तर पर होता है, जिससे पूरी तरह से अपनी स्वयं की निर्भरता को कॉन्फ़िगर करने की आवश्यकता से विश्लेषण मुक्त हो जाता है। इस प्रकार, कर्तव्यों का एक सख्त अलगाव प्राप्त किया जाता है।

ठंडे बस्ते में डालने के निर्णय

शायद उपरोक्त उदाहरण काफी पर्याप्त हैं, लेकिन इंटरफेस और निर्भरता इंजेक्शन के लिए अभी भी कई अन्य फायदे हैं। इंटरफेस विशिष्ट कार्यान्वयन के बारे में निर्णय लेने की अनुमति देते हैं। हालाँकि निर्णयों से हमें यह तय करने की आवश्यकता होती है कि हम किस व्यवहार का समर्थन करेंगे, फिर भी वे हमें विशिष्ट कार्यान्वयन के बारे में निर्णय लेने की अनुमति देते हैं। मान लीजिए कि हम जानते हैं कि हम स्वचालित लेनदेन करना चाहते थे, लेकिन अभी तक यह सुनिश्चित नहीं था कि हम किस प्रदाता का उपयोग करेंगे। डेटा वेयरहाउस के साथ काम करते समय समाधानों की एक समान श्रेणी को लगातार निपटाया जाता है। हमारे प्रोग्राम को क्या उपयोग करना चाहिए: mysql, postgres, redis, file system, cassandra? अंततः, यह सब कार्यान्वयन विवरण है, और इंटरफेस हमें इन मुद्दों पर अंतिम निर्णय लेने की अनुमति देते हैं। वे हमें अपने कार्यक्रमों के व्यावसायिक तर्क को विकसित करने की अनुमति देते हैं, और अंतिम समय पर विशिष्ट तकनीकी समाधान पर स्विच करते हैं!

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

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

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

भविष्य के लिए

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

 se.CurrentPrice(ticker)

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

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

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

सभी समान, आप ऐसा नहीं कर सकते! - लंबी अवधि के डिजाइन के लिए इंटरफेस और निर्भरता इंजेक्शन का उपयोग करना

More articles: