वैश्विक स्थिति। यह वाक्यांश हर उस डेवलपर के दिल में भय और दर्द पैदा करता है, जिसे इस घटना का सामना करने का दुर्भाग्य मिला है। क्या आप पहले से ही अप्रत्याशित आवेदन व्यवहार का सामना कर चुके हैं, इसके कारणों को नहीं समझ पा रहे हैं, जैसे एक दुखी शूरवीर कई सिर के साथ हाइड्रा को मारने की कोशिश कर रहा है? आप परीक्षण और त्रुटि के एक अंतहीन चक्र में समाप्त हो जाते हैं, 90% समय सोच रहा है कि क्या हो रहा है?

यह सब ग्लोबल्स के कष्टप्रद परिणाम हो सकते हैं: छिपे हुए चर जो अपने राज्य को अज्ञात स्थानों में बदलते हैं, उन कारणों के लिए जिन्हें आपने अभी तक पता नहीं लगाया है।

क्या आप आवेदन बदलने की कोशिश करते हुए अंधेरे में घूमना पसंद करते हैं? बेशक मुझे यह पसंद नहीं है। सौभाग्य से, मेरे पास आपके लिए मोमबत्तियाँ हैं:

1. सबसे पहले, मैं वर्णन करूंगा कि हम सबसे अधिक बार वैश्विक राज्यों को क्या कहते हैं। यह शब्द हमेशा सटीक रूप से उपयोग नहीं किया जाता है, इसलिए इसे स्पष्टीकरण की आवश्यकता होती है।
   
2. अगला, हमें पता चलेगा कि ग्लोबल्स हमारे कोड बेस के लिए हानिकारक क्यों हैं।
   
3. फिर मैं समझाऊंगा कि कैसे ग्लोबल्स के दायरे को स्थानीय चर में बदल दिया जाए।
   
4. अंत में, मैं इनकैप्सुलेशन के बारे में बात करूंगा और वैश्विक चर के खिलाफ धर्मयुद्ध बड़ी समस्या का हिस्सा क्यों है।
   

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

क्या आप तैयार हैं, प्रिय पाठक, घोड़े पर कूदने और अपने दुश्मन को जानने के लिए? इन ग्लोबल्स को खोजो और उन्हें हमारी तलवारों के स्टील का स्वाद दो!

एक शर्त क्या है?

आइए बुनियादी बातों से शुरू करें ताकि आप डेवलपर्स एक-दूसरे को समझ सकें।

एक राज्य एक प्रणाली या इकाई की एक परिभाषा है। राज्य वास्तविक जीवन में पाए जाते हैं:

• जब कंप्यूटर बंद किया जाता है, तो इसकी स्थिति बंद हो जाती है।
  
• जब एक कप चाय गर्म होती है, तो उसकी स्थिति गर्म होती है।
  

सॉफ्टवेयर विकास में, कुछ निर्माण (जैसे चर) में राज्य हो सकते हैं। मान लीजिए कि स्ट्रिंग "हैलो" या संख्या 11 को राज्य नहीं माना जाता है, वे मूल्य हैं। वे राज्य बन जाते हैं जब वे एक चर से जुड़े होते हैं और स्मृति में रखे जाते हैं।

<?php echo "hello"; // No state here! $lala = "hello"; // The variable $lala has the state 'hello'. 

दो प्रकार के राज्यों को अलग किया जा सकता है:

वैरिएबल स्टेट्स: उनके इनिशियलाइज़ेशन के बाद, वे किसी भी समय आपके एप्लिकेशन के निष्पादन के दौरान बदल सकते हैं।

 <?php $lala = "hello"; // Initialisation of the variable. $lala = "hallo"; // The state of the variable $lala can be changed at runtime. 

अपरिवर्तनीय स्थिति: निष्पादन के दौरान परिवर्तित नहीं हो सकती। आप अपने वैरिएबल को पहला राज्य असाइन करते हैं, और उसका मान बाद में नहीं बदलता है। रोज़मर्रा के जीवन में "निरंतर" को अपरिवर्तनीय राज्यों के उदाहरण कहा जाता है:

 <?php define("GREETING", "hello"); // Constant definition. echo GREETING; GREETING = "hallo"; // This line will produce an error! 

अब आइए डेनिस और वैसिली के बीच एक काल्पनिक वार्तालाप सुनें, जो आपके साथी डेवलपर्स:

- दान! आपने हर जगह वैश्विक चर बनाए हैं! उन्हें सब कुछ तोड़े बिना बदला नहीं जा सकता! मैं तुम्हें मार दूंगा!
- निफेगा, वासेक! मेरे वैश्विक भाग्य बहुत बढ़िया हैं! मैंने अपनी आत्मा उन में डाल दी, ये कृति हैं! मैं अपने दस्ताने पहनती हूं!

सबसे अधिक बार, डेवलपर्स वैश्विक राज्यों, वैश्विक चर या ग्लोबल्स को कहते हैं, जिन्हें उन्हें वैश्विक परिवर्तनशील राज्य कहना चाहिए। यही है, राज्यों कि आप के लिए उपलब्ध scopes के सबसे बड़े में संशोधित किया जा सकता है: पूरे आवेदन में।

जब एक चर में संपूर्ण अनुप्रयोग एक दायरे के रूप में नहीं होता है, तो हम स्थानीय चर या स्थानों के बारे में बात कर रहे हैं। वे दृश्यता के कुछ क्षेत्रों में मौजूद हैं, संपूर्ण अनुप्रयोग क्षेत्र से कम है।

 <?php namespace App\Ecommerce; $global = "I'm a mutable global variable!"; // global variable class Shipment { public $warehouse; // local variable existing in the whole class public function __construct() { $info = "You're creating a shipment object!"; // local variable bound to the constructor scope echo $info; } } class Product { public function __construct() { global $global; $global = "I change the state now 'cause I can!"; echo "You're creating a product object!"; // no state here } } 

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

यदि आप वास्तव में ऐसा सोचते हैं, तो मैं निरंतर पढ़ने की सलाह देता हूं।

वैश्विक राज्य प्लेग और हैजा से भी बदतर हैं?

सबसे बड़ा लिंक आरेख

तथ्य: आपके लिए एक सटीक एप्लिकेशन कनेक्शन आरेख बनाना आसान होगा, यदि इसमें केवल छोटे और परिभाषित स्कोप वाले स्थान हैं, बिना किसी भी परिमाण के।

क्यों?

मान लें कि आपके पास वैश्विक चर के साथ एक बड़ा अनुप्रयोग है। हर बार जब आपको कुछ बदलने की आवश्यकता होती है, तो आपको निम्न करना होगा:

• याद रखें कि ये परिवर्तनशील वैश्विक राज्य मौजूद हैं।
  
• अनुमान लगाएं कि क्या वे उस दायरे को प्रभावित करेंगे जो आप बदलने जा रहे हैं।
  

आमतौर पर, आपको उन स्थानीय चरों के बारे में सोचने की ज़रूरत नहीं है जो अन्य स्कोप में हैं, लेकिन जो कुछ भी आप करते हैं, आपको हमेशा अपने थके हुए मस्तिष्क को वैश्विक उत्परिवर्तित राज्यों के लिए एक स्थान पर रखने की आवश्यकता होती है, क्योंकि वे सभी स्कोप को प्रभावित कर सकते हैं।

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

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

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

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

वैश्विक नाम टकराव

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

• सबसे पहले, आपको यह पता लगाना होगा कि आपका पुस्तकालय वैश्विक चर का उपयोग करता है।
  
• दूसरे, आपको यह गणना करने की आवश्यकता है कि निष्पादन के दौरान किस चर का उपयोग किया गया था - आपका या पुस्तकालय? यह इतना आसान नहीं है, नाम समान हैं!
  
• तीसरा, चूंकि आप स्वयं पुस्तकालय नहीं बदल सकते हैं, इसलिए आपको अपने वैश्विक परिवर्तनशील चरों का नाम बदलना होगा। यदि पूरे आवेदन में उपयोग किया जाता है, तो आप रोएंगे।
  

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

परीक्षण एक बुरे सपने में बदल जाएगा

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

क्या आपने कभी ऐसा किया है कि अलगाव परीक्षण ठीक काम करते हैं, और जब आप पूरे पैकेज को चलाते हैं, तो क्या वे विफल होंगे? नहीं? और मेरे पास था। जब भी मुझे यह याद आता है, मुझे दुख होता है।

समसामयिक मुद्दे

यदि आप को संगामिति की आवश्यकता है, तो वैरिएबल ग्लोबल स्टेट्स बहुत सारी समस्याएं पैदा कर सकते हैं। जब आप निष्पादन के कई थ्रेड्स में ग्लोबल्स की स्थिति को बदलते हैं, तो दौड़ के एक शक्तिशाली राज्य में एड़ी पर सिर।

यदि आप एक PHP डेवलपर हैं, तो यह आपको परेशान नहीं करता है, जब तक कि आप उन पुस्तकालयों का उपयोग नहीं करते हैं जो आपको समानता पैदा करने की अनुमति देते हैं। हालांकि, जब आप एक नई भाषा सीखते हैं जिसमें समानता को लागू करना आसान होता है, तो मुझे उम्मीद है कि आप मेरे गद्य को याद करेंगे।

वैश्विक उत्परिवर्ती राज्यों से बचना

जबकि वैश्विक परिवर्तनशील राज्य समस्याओं का एक टन पैदा कर सकते हैं, वे कभी-कभी मुश्किल से बचते हैं।

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

वैश्विक उत्परिवर्ती राज्यों को भी भाषा कार्यान्वयन में सीधे समर्थन दिया जा सकता है। उदाहरण के लिए, PHP में सुपरग्लोबल्स होते हैं।

अगर ग्लोबल्स कहीं से आते हैं, तो उनसे कैसे निपटें? डेनिस के आवेदन को कैसे रिफ्लेक्टर करें, आपके साथी डेवलपर ने जहां भी संभव हो ग्लोबल्स बनाए, क्योंकि उन्होंने पिछले 20 वर्षों में विकास पर कुछ भी नहीं पढ़ा है?

कार्य तर्क

ग्लोबल्स से बचने का सबसे आसान तरीका फ़ंक्शन तर्कों का उपयोग करके चर पास करना है। एक सरल उदाहरण लें:

 <?php namespace App; use Router\HttpRequest; use App\Product\ProductData; use App\Exceptions; class ProductController { public function createAction(HttpRequest $httpReq) { $productData = $httpReq->get("productData"); if (!$this->productModel->validateProduct($productData)) { return ValidationException(sprintf("The product %d is not valid", $productData["id"])); } $product = $this->productModel->createProduct($productData); } } class Product { public function createProduct(array $productData): Product { $productData["name"] = "SuperProduct".$productData["name"]; // This is not what you should do; I talk about it later in the article. try { $product = $this->productDao->find($productData["id"]); return product; } catch (NotFoundException $e) { $product = $this->productDao->save($productData); return $product; } } } class ProductDao { private $db; public function find(int $id): array { return $this->db->find(['product' => $id]); } public function save(array $productData): array { return $this->db->saveProduct($productData); } } 

जैसा कि आप देख सकते हैं, HTTP अनुरोध के माध्यम से, नियंत्रक से $productData विभिन्न स्तरों के माध्यम से जाता है:

1. नियंत्रक को HTTP अनुरोध प्राप्त हुआ।
   
2. पैरामीटर्स मॉडल में पारित हुए।
   
3. पैरामीटर्स डीएओ को पास हुए ।
   
4. पैरामीटर्स एप्लिकेशन डेटाबेस में सहेजे जाते हैं।
   

जब हम इसे HTTP अनुरोध से प्राप्त करते हैं तो हम इस पैरामीटर को वैश्विक बना सकते हैं। यह बहुत सरल लगता है: 4 अलग-अलग कार्यों के लिए डेटा स्थानांतरित करने की कोई आवश्यकता नहीं है। हालाँकि, मापदंडों को कार्यों के तर्क के रूप में पारित करना:

• यह स्पष्ट रूप से दिखाएगा कि ये फ़ंक्शन $productData उपयोग करते हैं।
  
• यह स्पष्ट रूप से दिखाएगा कि कौन से कार्य कौन से मापदंडों का उपयोग करते हैं। यह देखा जा सकता है कि ProductDao::find $productData ProductDao::find $productData से ProductDao::find , केवल $id आवश्यकता है, और सब कुछ नहीं।
  

ग्लोबल्स कोड को एक-दूसरे के साथ कम समझने योग्य और सहयोगी तरीके बनाते हैं, जो लगभग पूर्ण अनुपस्थिति के फायदे के लिए बहुत अधिक कीमत है।

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

प्रश्न निष्पक्ष, प्रिय पाठक हैं। एक अच्छे डेवलपर के रूप में , आपको अपने संचार कौशल का उपयोग करके डेनिस को समझाना चाहिए, यह है:

“डेनिस, यदि आपके कार्यों में बहुत सारे तर्क हैं, तो कार्य स्वयं एक समस्या हो सकती है। वे शायद बहुत ज्यादा करते हैं, बहुत सी चीजों के लिए जिम्मेदार हैं। आपने उन्हें छोटे कार्यों में विभाजित करने के बारे में नहीं सोचा? " ।

एथेंस के एक्रोपोलिस में एक वक्ता की तरह लग रहा है, आप जारी रखते हैं:

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

यह अधिक जटिल हो सकता है जब आपके पास अधिक तर्क हो (शायद ऐसा है), लेकिन फिर से, नुकसान नुकसान से आगे निकलते हैं: यह बेहतर है कि कोड जितना संभव हो उतना स्पष्ट हो, और छिपे हुए वैश्विक उत्परिवर्तित राज्यों का उपयोग न करें।

प्रसंग वस्तु

प्रासंगिक वस्तुएं वे हैं जिनमें कुछ संदर्भ द्वारा परिभाषित डेटा होते हैं। आमतौर पर, यह डेटा कुंजी-जोड़ी निर्माण के रूप में संग्रहीत होता है, जैसे PHP में एक साहचर्य सरणी। ऐसी वस्तु का कोई व्यवहार नहीं है, केवल डेटा, एक मूल्य वस्तु के समान है ।

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

संदर्भ स्वयं क्वेरी होगा: एक अन्य क्वेरी - एक और संदर्भ - एक और डेटा सेट। फिर संदर्भ ऑब्जेक्ट को किसी भी विधि से पारित किया जाएगा जिसे इस डेटा की आवश्यकता है।

आप कहते हैं: "यह बहुत बढ़िया है और यह सब है, लेकिन यह क्या देता है?"

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

लेकिन विकास में हर चीज की एक कीमत होती है। प्रसंग वस्तुएं हानिकारक हो सकती हैं:

• फ़ंक्शन के तर्कों को देखते हुए, आप यह नहीं जान पाएंगे कि संदर्भ ऑब्जेक्ट में डेटा क्या है।
  
• आप किसी भी वस्तु को संदर्भ वस्तु में रख सकते हैं। उदाहरण के लिए, संपूर्ण उपयोगकर्ता सत्र, या यहां तक ​​कि आपके अधिकांश एप्लिकेशन डेटा को न डालें। और फिर यह हो सकता है: $context->getSession()->getUser()->getProfil()->getUsername() । Demeter के कानून को तोड़ें, और आपका अभिशाप पागलपन की जटिलता होगी।
  
• संदर्भ वस्तु जितनी बड़ी होगी, यह पता लगाना उतना ही कठिन होगा कि वह किस डेटा और किस स्कोप का उपयोग करती है।
  

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

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

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

ग्लोबल म्यूटेबल स्टेट्स का एक और अच्छा विकल्प यह होगा कि आप डेटा को सीधे उस ऑब्जेक्ट में एम्बेड करें जब आप इसे बनाते हैं। यह निर्भरता इंजेक्शन की परिभाषा है: आपके घटकों (कक्षाओं) में वस्तुओं को एम्बेड करने के लिए तकनीकों का एक सेट।

वास्तव में निर्भरता इंजेक्शन क्यों?

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

निर्भरता इंजेक्शन अनुप्रयोग जीवन चक्र को दो महत्वपूर्ण चरणों में विभाजित करता है:

1. एप्लिकेशन ऑब्जेक्ट बनाना और उनकी निर्भरता को लागू करना।
   
2. अपने लक्ष्यों को प्राप्त करने के लिए वस्तुओं का उपयोग करें।
   

यह दृष्टिकोण कोड को स्पष्ट करता है; आपको यादृच्छिक स्थानों में सब कुछ तत्काल करने की आवश्यकता नहीं है, या इससे भी बदतर, हर जगह वैश्विक वस्तुओं का उपयोग करें।

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

कंस्ट्रक्टर या सेटरों के माध्यम से कार्यान्वयन

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

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

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

उल्लंघन उल्लंघन

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

क्या आपने एनकैप्सुलेशन कहा?

वैश्विक राज्यों का उपयोग करने से अंततः एनकैप्सुलेशन टूट जाएगा, जैसे आप इसे स्थानीय राज्यों के साथ तोड़ सकते हैं।

शुरू से शुरू करते हैं। विकिपीडिया हमें एनकैप्सुलेशन की परिभाषा के बारे में क्या बताता है? किसी वस्तु के कुछ घटकों तक सीधी पहुँच को सीमित करने के लिए भाषा तंत्र। प्रवेश प्रतिबंध? क्यों?

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

बढ़ता दायरा और राज्य रिसाव

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

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

मैं एक महत्वपूर्ण विचार व्यक्त करना चाहता हूं: यदि आप वैश्विक परिवर्तनशील राज्यों से बचते हैं, तो इसका मतलब यह नहीं है कि आप आराम कर सकते हैं, एक हाथ में कॉकटेल पकड़ सकते हैं, और दूसरे के साथ बटन दबा सकते हैं, जीवन और अपने पौराणिक कोड का आनंद ले सकते हैं। -, , -, , .

, . , .

? - . , , -.

, - , , . , , — . , : , . . .

. Product , , :

 class Product { public function createProduct(array $productData): Product { $productData["name"] = "SuperProduct".$productData["name"]; // This is not what you should do; I talk about it later in the article. try { $product = $this->productDao->find($productData["id"]); return product; } catch (NotFoundException $e) { $product = $this->productDao->save($productData); return $product; } } } 

$productData . , , , .

, . , - ? , . .

, , . .

:

 class Product { public function createProduct(array $productData): Product { // Since $productData is passed to other variable, it has to be immutable. $name = "SuperProduct".$productData["name"]; try { $product = $this->productDao->find($productData["id"]); return product; } catch (NotFoundException $e) { $product = $this->productDao->save($name, $productData); return $product; } } } 

, , $productData . , . $productData , , HTTP-.

, : «, ».

?

. , .

?

• , , .
  
• , , (, ) .
  

. , .

, ShipmentDelay , , , . , -, ShipmentDelay , , , . ? , DRY .

, , . : , , . , , , . , , .

?

, (, ), , , . , , , , .

. :

• .
  
• , .
  
• — : , , .
  
• , .
  

. , — . , .

, , .

, , . , . , , . , !