हा, डि के तहत सेवा लोकेटर का एक सुंदर भेस क्या है। यह भी एक डि की तरह लग सकता है! :-)

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

(केडीपीवी का कोई मतलब नहीं है और यह मुख्य रूप से इस प्रकाशन की दृश्य पहचान के लिए है, दूसरों के बीच)

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

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

संक्षेप में DI - आवश्यकता / आयात मॉड्यूल के बजाय, आप निर्माण पैरामीटर (या संपत्ति सेटर) के माध्यम से निर्भरता को इंजेक्ट करते हैं। यही है, इस बड़े शब्द के पीछे सरल है "निर्माण मापदंडों के माध्यम से पास की निर्भरता"।

राइज़ियोमॉम के सहकर्मी की यह टिप्पणी काफी सटीक रूप से घटना का सार बताती है। कोड की डेवलपर की समझ को सुविधाजनक बनाने के लिए, सभी निर्भरताएं स्पष्ट रूप से वर्णित हैं - निर्माण मापदंडों के रूप में (आमतौर पर, लेकिन हमेशा):

class MainClass { public function __construct($dep1, $dep2, $dep3) {} } 

वह सब है। DI - वह उस बारे में है। हमें जिन आश्रितों की आवश्यकता है, वे वहां किसी के द्वारा प्रदान की जाती हैं। और जहां यह "किसी को वहाँ से बाहर" ले जाता है - डीआई परवाह नहीं करता है।

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

 function f(dep1, dep2, dep3) {} 

एक कंस्ट्रक्टर अन्य सभी के बीच ऐसा ही एक विशेष तरीका है।

सेवा लोकेटर

सेवा लोकेटर एक प्रसिद्ध विरोधी पैटर्न है। वह क्या करता है? एक वस्तु को अन्य वस्तुओं तक पहुंच प्रदान करता है। यहाँ इस तरह के लोकेटर के लिए एक विशिष्ट इंटरफ़ेस है:

 interface ServiceLocator { public function addInstance(string $class, Service $service); public function addClass(string $class, array $params); public function has(string $interface): bool; public function get(string $class): Service; } 

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

सेवा लोकेटर वस्तुओं को संग्रहीत करने और उन तक पहुंच प्रदान करने के लिए जिम्मेदार है। वह सब है।

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

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

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

यहाँ, उदाहरण के लिए, सिम्फनी DI कंटेनर इंटरफ़ेस है:

 interface ContainerInterface extends PsrContainerInterface { public function set(string $id, ?object $service); public function get($id, int $invalidBehavior = self::EXCEPTION_ON_INVALID_REFERENCE); public function has($id); public function initialized(string $id); public function getParameter(string $name); public function hasParameter(string $name); public function setParameter(string $name, $value); } 

यदि आवश्यक हो, तो आप अपने आप को बहुत आसानी से समझा सकते हैं कि डीआई कंटेनर का इंटरफ़ेस लोकेटर सर्विसेज के इंटरफ़ेस के समान है - समान get , has और set / add ।

सेवा लोकेटर खराब क्यों है?

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

 public class OrderProcessor : IOrderProcessor { public void Process(Order order) { var validator = Locator.Resolve<IOrderValidator>(); if (validator.Validate(order)) { var shipper = Locator.Resolve<IOrderShipper>(); shipper.Ship(order); } } } 

जैसे, यह इतना बुरा है, लेकिन अच्छा है - इस तरह:

 public class OrderProcessor : IOrderProcessor { public OrderProcessor(IOrderValidator validator, IOrderShipper shipper) public void Process(Order order) } 

अरे, हमने सिर्फ IOrderValidator और IOrderShipper साथ ऑब्जेक्ट्स बनाने के क्षण के ब्रैकेट को IOrderValidator है! यह संभव है कि इस एप्लिकेशन में कहीं और कुछ इस कोड की तरह है:

 var validator = Locator.Resolve<IOrderValidator>(); var shipper = Locator.Resolve<IOrderShipper>(); var processor = new OrderProcessor(validator, shipper); processor.Process(order); 

रचना जड़

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

असेंबली पॉइंट पर, सभी निर्भरताएँ स्पष्ट रूप से परिभाषित की जाती हैं, जहां वे प्रतीक्षा कर रहे हैं, उसी ऑब्जेक्ट को बनाया और कार्यान्वित किया जाता है। यहाँ सेवाओं लोकेटर और DI कंटेनर के बीच अंतर न्यूनतम हैं। संग्रहीत वस्तुओं को निकालने के लिए दोनों और दूसरी नई वस्तुओं को बनाने की अनुमति देते हैं। मैं यहां तक ​​कहूंगा कि इस जगह पर उनके बीच कोई बुनियादी मतभेद नहीं हैं।

मुख्य अंतर

और DI लोकेटर और कंटेनर की सेवाओं लोकेटर के बीच अंतर सबसे स्पष्ट कहाँ हैं? किसी अन्य स्थान पर, और विशेष रूप से कंटेनर तक स्थिर पहुंच के साथ:

 $obj = Container::getInstance()->get($objId); 

यहाँ यह है। इस रूप में, कहीं भी (जब तक कि यह एक असेंबली प्वाइंट नहीं है, लेकिन वहां स्थैतिक पहुंच का उपयोग बहुत संदिग्ध है), कोई भी कंटेनर सर्विस लोकेटर नामक एक विरोधी पैटर्न बन जाता है।

एक VolCh सहकर्मी ने संक्षेप में और मेरे सवाल का जवाब दिया:

और आपको कैसे लगता है कि सच्चा DI एक DI के रूप में प्रच्छन्न सेवा लोकेटर से अलग है?

इस तरह:

कंटेनर का उपयोग

वास्तव में, यह पूरा प्रकाशन यहाँ उनके उत्तर की एक अधिक विस्तृत तैनाती है।

कंटेनर का कानूनी उपयोग

इस प्रकार, चाहे कंटेनर एक DI कंटेनर हो या सेवा लोकेटर के लिए एक कंटेनर बहुत निर्भर करता है कि हम इसका उपयोग कहां और कैसे करते हैं। जैसा कि मैंने ऊपर कहा, विधानसभा बिंदु पर, कंटेनरों के प्रकारों के बीच का अंतर गायब हो जाता है। लेकिन अगर कंटेनर खुद किसी वर्ग के लिए निर्भरता है तो हम क्या करेंगे?

 class Foo { public function __construct(Container $container){} } 

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

 class Foo { private $dep; public function __construct(Container $container) { $this->dep = $container->get('depId'); } } 

 class Foo { private $container; public function __construct(Container $container) { $this->container = $container; } public function initModules($modules) { foreach ($modules as $initClassId) { $init= $this->container->get($initClassId); $init->exec(); } } } 

सारांश

वास्तव में, सब कुछ कुछ अधिक जटिल है, DI कंटेनर में सेवा लोकेटर की तुलना में अधिक कार्यक्षमता होनी चाहिए, लेकिन इस प्रकाशन का सार यह है कि यहां तक ​​कि सबसे परिष्कृत DI कंटेनर को सेवा लोकेटर के रूप में आसानी से उपयोग किया जा सकता है, लेकिन सेवा लोकेटर का उपयोग करने के लिए DI कंटेनर के रूप में - आपको प्रयास करने की आवश्यकता है।

पुनश्च
मैं सर्गेई टेप्लाकोव के प्रोग्रामिंग सामान ब्लॉग के लिंक प्रदान करने में मदद नहीं कर सकता - ये मुद्दे वहां बहुत अच्छी तरह से कवर किए गए हैं।