PHP में OOP अनुप्रयोगों में ऑब्जेक्ट्स को इनिशियलाइज़ करने की समस्या। रजिस्ट्री, फैक्ट्री मेथड, सर्विस लोकेटर, और डिपेंडेंसी इंजेक्शन पैटर्न का उपयोग करके समाधान खोजना

यह सिर्फ इतना हुआ कि प्रोग्रामर डिजाइन पैटर्न के रूप में सफल समाधान तय करते हैं। पैटर्न पर बहुत साहित्य है। एरच गामा, रिचर्ड हेल्म, राल्फ जॉनसन और जॉन वलिसाइड्स द्वारा चार गैंग्स "डिज़ाइन पैटर्न" की पुस्तक और, शायद, मार्टिन फॉवलर द्वारा "पैटर्न ऑफ़ एंटरप्राइज एप्लीकेशन आर्किटेक्चर" निश्चित रूप से क्लासिक्स माना जाता है। मैंने पीएचपी में उदाहरणों के साथ जो पढ़ा है, वह सबसे अच्छा है। - यह मैट जैंडस्ट्रा द्वारा "PHP ऑब्जेक्ट्स, पैटर्न और प्रैक्टिस" है । ऐसा हुआ है कि यह सभी साहित्य उन लोगों के लिए काफी जटिल है, जिन्होंने अभी-अभी OOP में महारत हासिल करना शुरू किया है। इसलिए, मेरे पास कुछ पैटर्न पेश करने का विचार था जो मुझे लगता है कि सबसे उपयोगी हैं। सरलीकृत: दूसरे शब्दों में, यह लेख डिजाइन पैटर्न की व्याख्या करने का मेरा पहला प्रयास है। में tion KISS शैली।
आज हम इस बारे में बात करेंगे कि ओओपी एप्लिकेशन में वस्तुओं के आरंभीकरण के साथ क्या समस्याएं पैदा हो सकती हैं और इन समस्याओं को हल करने के लिए आप कुछ लोकप्रिय डिजाइन पैटर्न का उपयोग कैसे कर सकते हैं।

उदाहरण

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

class Grabber { public function get($url) {/** returns HTML code or throws an exception */} } 

एक और वर्ग बनाएं जिसकी वस्तुएं परिणामी HTML को फ़िल्टर करने के लिए जिम्मेदार होंगी। फ़िल्टर विधि HTML कोड और CSS चयनकर्ता को तर्क के रूप में लेती है, और इसे दिए गए चयनकर्ता द्वारा पाए गए तत्वों की एक सरणी वापस करने देती है।

 class HtmlExtractor { public function filter($html, $selector) {/** returns array of filtered elements */} } 

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

 class GoogleFinder { private $grabber; private $filter; public function __construct() { $this->grabber = new Grabber(); $this->filter = new HtmlExtractor(); } public function find($searchString) { /** returns array of founded results */} } 

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

 class GoogleFinder { private $grabber; private $filter; public function __construct(Grabber $grabber, HtmlExtractor $filter) { $this->grabber = $grabber; $this->filter = $filter; } public function find($searchString) { /** returns array of founded results */} } 

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

 class Controller { public function action() { /* Some stuff */ $finder = new GoogleFinder(new Grabber(), new HtmlExtractor()); $results = $finder->find('search string'); /* Do something with results */ } } 

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

रजिस्ट्री टेम्पलेट।

इसलिए, हमने विन्यास में वस्तुओं के निर्माण का निर्णय लिया। चलो करते हैं।

 $registry = new ArrayObject(); $registry['grabber'] = new Grabber(); $registry['filter'] = new HtmlExtractor(); $registry['google_finder'] = new GoogleFinder($registry['grabber'], $registry['filter']); 

हम केवल हमारे ArrayObject को कंट्रोलर को पास कर सकते हैं और समस्या हल हो गई है।

 class Controller { private $registry; public function __construct(ArrayObject $registry) { $this->registry = $registry; } public function action() { /* Some stuff */ $results = $this->registry['google_finder']->find('search string'); /* Do something with results */ } } 

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

फैक्टरी विधि

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

 class Factory { public function getGoogleFinder() { return new GoogleFinder($this->getGrabber(), $this->getHtmlExtractor()); } private function getGrabber() { return new Grabber(); } private function getHtmlExtractor() { return new HtmlFiletr(); } } 

एक नियम के रूप में, कारखानों को बनाया जाता है जो एक प्रकार की वस्तु बनाने के लिए जिम्मेदार होते हैं। कभी-कभी एक कारखाना संबंधित वस्तुओं का एक समूह बना सकता है। वस्तुओं को फिर से बनाने से बचने के लिए हम एक संपत्ति में कैशिंग का उपयोग कर सकते हैं।

 class Factory { private $finder; public function getGoogleFinder() { if (null === $this->finder) { $this->finder = new GoogleFinder($this->getGrabber(), $this->getHtmlExtractor()); } return $this->finder; } } 

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

 class Controller { private $factory; public function __construct(Factory $factory) { $this->factory = $factory; } public function action() { /* Some stuff */ $results = $this->factory->getGoogleFinder()->find('search string'); /* Do something with results */ } } 

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

सेवा लोकेटर

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

• सेवा (सेवा) - एक समाप्त वस्तु जो कंटेनर से प्राप्त की जा सकती है।
• सेवा विवरण (सेवा परिभाषा) - सेवा को शुरू करने के लिए तर्क।
• एक कंटेनर (सर्विस कंटेनर) एक केंद्रीय वस्तु है जो सभी विवरणों को संग्रहीत करता है और उनसे सेवाएं बना सकता है।

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

 class ServiceContainer extends ArrayObject { public function get($key) { if (is_callable($this[$key])) { return call_user_func($this[$key]); } throw new \RuntimeException("Can not find service definition under the key [ $key ]"); } } 

फिर परिभाषाएँ पंजीकरण इस तरह दिखेगा:

 $container = new ServiceContainer(); $container['grabber'] = function () { return new Grabber(); }; $container['html_filter'] = function () { return new HtmlExtractor(); }; $container['google_finder'] = function() use ($container) { return new GoogleFinder($container->get('grabber'), $container->get('html_filter')); }; 

और इस तरह नियंत्रक में उपयोग करें:

 class Controller { private $container; public function __construct(ServiceContainer $container) { $this->container = $container; } public function action() { /* Some stuff */ $results = $this->container->get('google_finder')->find('search string'); /* Do something with results */ } } 

सेवा कंटेनर बहुत सरल हो सकता है, लेकिन बहुत जटिल हो सकता है। उदाहरण के लिए, सिम्फनी सर्विस कंटेनर बहुत सारी संभावनाएं प्रदान करता है: पैरामीटर, पैरामीटर, सेवाओं के दायरे, टैग, एलियास, निजी सेवाओं द्वारा सेवाओं की खोज, सभी सेवाओं को जोड़ने के बाद कंटेनर में परिवर्तन करने की क्षमता। (कंपाइलर पास) और भी बहुत कुछ। DIExtraBundle आगे मानक कार्यान्वयन का विस्तार करता है।
लेकिन वापस हमारे उदाहरण पर। जैसा कि आप देख सकते हैं, सेवा लोकेटर न केवल उन सभी समस्याओं को पिछले टेम्पलेट्स के रूप में हल करता है, बल्कि अपनी स्वयं की सेवा परिभाषाओं के साथ मॉड्यूल का उपयोग करना भी आसान बनाता है।
इसके अलावा, ढांचे के स्तर पर, हमें अमूर्तता का एक अतिरिक्त स्तर प्राप्त हुआ। अर्थात्, ServiceContainer :: विधि प्राप्त करके, हम, उदाहरण के लिए, वस्तु को प्रॉक्सी से बदल सकते हैं। और प्रॉक्सी ऑब्जेक्ट्स का दायरा केवल डेवलपर की कल्पना से सीमित है। यहां आप AOP प्रतिमान, और LazyLading आदि को लागू कर सकते हैं।
लेकिन, अधिकांश डेवलपर्स अभी भी सेवा लोकेटर को एक विरोधी पैटर्न मानते हैं। क्योंकि, सिद्धांत रूप में, हमारे पास किसी भी तथाकथित संख्या हो सकती है कंटेनर अवेयर क्लासेस (यानी वे वर्ग जिनमें कंटेनर का संदर्भ होता है)। उदाहरण के लिए, हमारे नियंत्रक, जिसके अंदर हम कोई भी सेवा प्राप्त कर सकते हैं।
आइए देखें कि यह क्यों खराब है।
पहले, फिर से, परीक्षण। केवल परीक्षणों में उपयोग की जाने वाली कक्षाओं के लिए मोक बनाने के बजाय, आपको पूरे कंटेनर में मोक करना होगा या असली कंटेनर का उपयोग करना होगा। पहला विकल्प सूट नहीं करता है, क्योंकि मुझे परीक्षणों में बहुत सारे अनावश्यक कोड लिखना होगा, दूसरा, क्योंकि यह इकाई परीक्षण के सिद्धांतों का खंडन करता है, और सहायक परीक्षणों के लिए अतिरिक्त लागत का कारण बन सकता है।
दूसरे, हमारे लिए रिफलेक्टर करना मुश्किल होगा। कंटेनर में किसी भी सेवा (या ServiceDefinition) को बदलकर, हम सभी निर्भर सेवाओं की जांच करने के लिए भी मजबूर होंगे। और यह समस्या IDE के उपयोग से हल नहीं होती है। पूरे आवेदन में ऐसे स्थान ढूंढना इतना सरल नहीं होगा। आश्रित सेवाओं के अलावा, आपको उन सभी स्थानों की भी जांच करने की आवश्यकता होगी जहां कंटेनर से रिफैक्ट की गई सेवा प्राप्त होती है।
खैर, तीसरा कारण यह है कि कंटेनर से सेवाओं के अनियंत्रित झटके जल्दी या बाद में कोड में गड़बड़ी और अनावश्यक भ्रम पैदा करेंगे। यह समझाना मुश्किल है, आपको केवल यह समझने के लिए अधिक से अधिक समय बिताने की आवश्यकता है कि कोई विशेष सेवा कैसे काम करती है, दूसरे शब्दों में, आप पूरी तरह से समझ सकते हैं कि कोई वर्ग क्या करता है या अपने सभी स्रोत कोड को पढ़कर कैसे काम करता है।

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

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

 $container['google_finder'] = function() use ($container) { return new Controller(Grabber $grabber); }; 

और नियंत्रक में कंटेनर से छुटकारा पाएं:

 class Controller { private $finder; public function __construct(GoogleFinder $finder) { $this->finder = $finder; } public function action() { /* Some stuff */ $results = $this->finder->find('search string'); /* Do something with results */ } } 

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

निष्कर्ष

ठीक है, अब यह कहा गया है कि सभी को खटकने का समय है। और यह बहुत कुछ कहा गया था ... :)
इसलिए, वस्तुओं को बनाने के काम को तैयार करने के लिए, हम निम्नलिखित पैटर्न का उपयोग कर सकते हैं:

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

   class ServiceContainer extends ArrayObject { public function get($key) { if (is_callable($this[$key])) { $obj = call_user_func($this[$key]); if ($obj instanceof RequestAwareInterface) { $obj->setRequest($this->get('request')); } return $obj; } throw new \RuntimeException("Can not find service definition under the key [ $key ]"); } } 

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

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

मजा आ गया!

PS बहुत-बहुत धन्यवाद, सभी ने जो समय लिया और मदद के लिए मेरे अनुरोध का जवाब दिया। आपकी राय जानना मेरे लिए महत्वपूर्ण था;)