मैं PHP में प्रोग्रामिंग कर रहा हूँ। और JS पर थोड़ा सा। एक बार जब मैंने Java में प्रोग्राम किया, उससे भी पहले - LotusScript । python और dart का स्वाद लेने की कोशिश की। Basic , Fortran , Pascal , Prolog , VisualBasic , ++ / , perl - इस सब पर मैंने कुछ निष्पादन योग्य भी चित्रित किया। कंप्यूटर एप्लिकेशन बनाने के मामले में प्रोग्रामिंग लैंग्वेज मेरी रुचि रखते हैं। वेब अनुप्रयोग। परिष्कृत वेब अनुप्रयोग। जो लोग एक दूसरे से अपरिचित लिखते हैं। अधिक सटीक रूप से, वे व्यक्तिगत रूप से अपरिचित हैं - वे एक दूसरे को आम भंडार में कमिटमेंट और बग ट्रैकर्स में उपनामों से जानते हैं। मैं विभिन्न ओएस के लिए / ++ में प्रोग्राम करने के लिए बहुत स्मार्ट नहीं हूं, और इसलिए मैं Magento के लिए PHP में प्रोग्रामिंग कर रहा हूं।

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

इस पाठ में, नाम स्थान से, मेरा मतलब PHP के दृष्टिकोण से नाम स्थान है, python के दृष्टिकोण से नाम स्थान नहीं:

 <?php namespace Vendor\Project\Module\Component\Unit; 

पहली बार, मैं Java सीखने के दौरान एक नाम स्थान पर आया, जब मैंने " पैकेज " निर्देश के रहस्य को समझने की कोशिश की:

 package com.sun.source.util; 

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

निर्भरता प्रबंधक

निर्भरता प्रबंधकों ने मुझे नामस्थान का अर्थ समझने में मदद की। यदि आपका कोड तृतीय-पक्ष कोड का उपयोग करता है, जो अन्य पैकेजों पर निर्भर करता है जो तीसरे लोगों पर निर्भर करता है, तो ऐसे डंप में ऑर्डर बनाए रखना बहुत मुश्किल है। फिर भी, JARs के ढेर को एक निर्देशिका (उदाहरण के लिए, WEB-INF/lib ) में ढेर करने के लिए बैक-डोमेन नियम के कारण, यह नेविगेट करने के लिए काफी आसान है:

npm ( JavaScript ) के साथ तुलना करें:

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

PHP , composer निर्भरता प्रबंधक एक दो-स्तरीय निर्देशिका संरचना बनाता है: / ./company/module / ./company/module :

जो एकल-स्तरीय आवंटन पर निर्भरता नेविगेशन में कुछ लाभ देता है।

यहां Java / JS / PHP लिए केंद्रीय पैकेज रिपॉजिटरी के आंकड़े दिए गए हैं:

https://mvnrepository.com/repos/central - 3 358 578 अनुक्रमित जार
https://www.npmjs.com/ - 872 459 पैकेज
https://packagist.org/statistics - 207 560 पैकेज (1,472,944 संस्करण)

maven लिए सबसे अधिक संभावना है maven मॉड्यूल के सभी संस्करणों को आंकड़ों में ध्यान में रखा जाता है, जबकि मॉड्यूल खुद को npm और composer में ध्यान में रखा जाता है।

नाम स्थान क्या है?

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

Java ( package ) और PHP ( namespace ) संस्करणों के अनुसार namespace , सर्वप्रथम, समुच्चयबोधक समूह में विशिष्ट कोड तत्व को स्पष्ट रूप से संबोधित करने की अनुमति देता है। और यह नेमस्पेस (लॉजिकल ग्रुपिंग) की एक संपत्ति है जो डेवलपर्स के कम जुड़े समूहों द्वारा अधिक जटिल सॉफ्टवेयर सिस्टम बनाना संभव बनाता है।

सॉफ्टवेयर तत्वों को संबोधित करना

PHP \Doctrine\DBAL\Schema\Column वर्ग विशिष्ट रूप से संबोधित किया जाता है, कोई फर्क नहीं पड़ता कि स्रोत कोड परियोजना से कैसे जुड़ा है। आईडीई इस पते को आसानी से बना सकता है। PhpStorm में, यह इस तरह किया जाता है (एक कोड तत्व पर राइट-क्लिक करें):

यदि आप JS कोड (जहाँ कोई नामस्थान नहीं हैं) के समान तकनीक लागू करने पर वही PhpStorm खो जाता है। आइए, JS query फ़ंक्शन के लिंक का पता इस तरह से बनाने की कोशिश करें:

आउटपुट module.query , जो पर्याप्त जानकारीपूर्ण नहीं है।

प्रलेखन (पत्राचार, बग ट्रैकर, आदि) में query फ़ंक्शन को संबोधित करने के लिए, आपको फ़ाइल में कोड की एक विशिष्ट रेखा का उल्लेख करना होगा:

परिणाम : ./node_modules/express/lib/middleware/query.js:25 : ./node_modules/express/lib/middleware/query.js:25

बेशक, किसी फ़ाइल में लाइनों की संख्या बदलने या फ़ाइल का नाम बदलने / स्थानांतरित करने के दौरान, हमें प्रलेखन में हमारे लिए रुचि के कार्यक्रम तत्व का एक पुराना पता होगा।

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

कोड के परस्पर विरोधी संस्करणों का पता लगाना

निर्भरता प्रबंधकों ( maven , composer , npm , ...) के बिना आधुनिक जटिल अनुप्रयोगों को विकसित नहीं किया जा सकता है। उसी समय, हमारी निर्भरताएं उनकी निर्भरता को खींचती हैं, जो स्वयं को खींचती हैं, आदि, जिसके परिणामस्वरूप विभिन्न निर्भरता ( जार नरक ) के माध्यम से खींचे गए एक ही पैकेज के लिए संस्करण संघर्ष हो सकते हैं।

JS नामस्थान की कमी के कारण ऐसा नहीं होता है। मैं खुद एक स्थिति में आया था जब मैगेंटो में अतिरिक्त मॉड्यूल स्थापित करते समय, उनके द्वारा लोड किए गए jQuery लाइब्रेरी के विभिन्न संस्करणों की संख्या 5-6 से अधिक थी। एक तरफ, इस तरह का व्यवहार डेवलपर्स को खुद को अधिक स्वतंत्रता देता है, दूसरी तरफ - अधिक स्वतंत्रता योग्यता पर अधिक मांग करती है। खैर, निर्भरता के ऐसे बहु-संस्करण नूडल में त्रुटियों की खोज - योग्यता इन बहुत गलतियों को बनाने के लिए योग्यता से एक आदेश या दो अधिक है।

PHP में नेमस्पेस का उपयोग करने से IDE स्तर पर इस तरह के संघर्षों का पता लगाना आसान हो जाता है (उदाहरण के लिए, मैंने दूसरी फाइल को क्लास के डुप्लिकेट के साथ बनाया):

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

कोड स्टार्टअप

PHP में spl_autoload_register फ़ंक्शन डेवलपर को उसकी कक्षाओं के स्रोतों के साथ फ़ाइलों को ठीक से परेशान नहीं होने देता है जहां स्थित हैं। किसी भी परियोजना में, आप इस फ़ंक्शन को ओवरराइड कर सकते हैं और वर्ग नाम से अपनी स्वयं की स्क्रिप्ट लोडिंग एल्गोरिदम को लागू कर सकते हैं। एक नामस्थान के उपयोग के बिना, एक जटिल परियोजना के भीतर अपनी विशिष्टता सुनिश्चित करने के लिए कक्षाओं के लिए काफी घुंघराले नामों को लिखना आवश्यक था (विशेषकर तीसरे पक्ष के पुस्तकालयों को ध्यान में रखते हुए)। Zend1 डेटाबेस के साथ काम करने के लिए सार एडेप्टर को निम्नानुसार परिभाषित किया गया था:

 abstract class Zend_Db_Adapter_Abstract {} 

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

Zend2 , जहां नामस्थान पहले से ही उपयोग किए जाते हैं, एक समान वर्ग परिभाषा इस प्रकार दिखाई देती है:

 namespace Zend\Db\Adapter; class Adapter implements ... {} 

कोड अंततः अधिक पठनीय हो जाता है, लेकिन नेमस्पेस का उपयोग करने का सबसे महत्वपूर्ण परिणाम वर्ग लोडर की कार्यक्षमता को एकीकृत करने की संभावना है, जो फाइल संरचना के लिए कक्षाओं के तार्किक पदानुक्रम के बंधन के साथ है। यहाँ ./vendor/composer/autoload_namespaces.php फ़ाइल का एक अंश दिया गया है जो composer PHP में ./vendor/autoload.php लोडर को काम करने के लिए बनाता है।

 <?php $vendorDir = dirname(dirname(__FILE__)); $baseDir = dirname($vendorDir); return array( 'Zend_' => array($vendorDir . '/magento/zendframework1/library'), 'Yandex' => array($vendorDir . '/allure-framework/allure-codeception/src', $vendorDir . '/allure-framework/allure-php-api/src', $vendorDir . '/allure-framework/allure-php-api/test'), 'Prophecy\\' => array($vendorDir . '/phpspec/prophecy/src'), 'PhpOption\\' => array($vendorDir . '/phpoption/phpoption/src'), 'PhpCollection' => array($vendorDir . '/phpcollection/phpcollection/src'), 'PHPMD\\' => array($vendorDir . '/phpmd/phpmd/src/main/php'), 'OAuth\\Unit' => array($vendorDir . '/lusitanian/oauth/tests'), 'OAuth' => array($vendorDir . '/lusitanian/oauth/src'), ... 

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

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

आईओसी

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

सारांश

उपरोक्त के प्रकाश में, मेरा मानना ​​है कि प्रोग्रामिंग लैंग्वेज जो मूल रूप से अपने तत्वों के लॉजिकल ग्रुपिंग का उपयोग करते हुए नाम स्रोत से संरचना कोड का उपयोग करती हैं, उन भाषाओं की तुलना में कम लागत के साथ अधिक जटिल एप्लिकेशन बनाने की अनुमति देती हैं जिनमें लॉजिकल ग्रुपिंग नहीं होती है। तदनुसार, Java / PHP / C++ / ... में बनाए जा सकने वाले अनुप्रयोगों की अधिकतम जटिलता डेवलपर्स द्वारा JavaScript / Python / C / ... में समान योग्यता के साथ हासिल नहीं की जा सकती है।