أنا البرمجة في PHP . وقليلا على JS . بمجرد البرمجة في Java ، حتى قبل ذلك - في LotusScript . حاول طعم python dart . Basic ، Fortran ، Pascal ، Prolog ، VisualBasic ، ++ / ، perl - على كل هذا أنا أيضا صورت شيئا قابلا للتنفيذ. لغات البرمجة تهمني من حيث إنشاء تطبيقات الكمبيوتر. تطبيقات الويب. تطبيقات الويب المتطورة. أولئك الذين يكتبون الناس غير مألوفين مع بعضهم البعض. بتعبير أدق ، فهم غير مألوفين شخصيًا - فهم يعرفون بعضهم البعض عن طريق التوقيعات التي تلتزم بالمستودع المشترك والأسماء المستعارة في متتبعات الأخطاء. أنا لست ذكيًا جدًا على البرمجة في / ++ لأنظمة التشغيل المختلفة ، وبالتالي فأنا أبرمج في PHP لـ Magento .

لذا ، بالعودة إلى موضوع المقال ، يمكنني القول أن مساحة الاسم هي إحدى الركائز المهمة للغاية التي تعتمد عليها كتابة تطبيقات الويب المعقدة على مجموعة من المطورين غير المألوفين مع بعضهم البعض.

في هذا النص ، من خلال مساحة الاسم ، أعني مساحة الاسم من وجهة نظر 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 لم JS ذلك. نتيجة لذلك ، في Java يمكنك إنشاء عدد كبير من الحزم (الوحدات) الخالية من التعارض بشكل مستقل دون الاتفاق صراحة على أسمائها كمجموعات تطوير مستقلة ، وفي JS يجب عليك استخدام سجل npm بشكل صريح. نعم ، في Java ، يكون سجل النطاق العالمي متضمنًا ضمنيًا في حل التعارضات ، ولكن يمكن لأي مجتمع ، وليس فقط برامج تشفير Java ، استخدام نفس قاعدة التسمية.

في PHP ، ينشئ مدير تبعية composer بنية دليل على ./company/module : ./company/module :

الذي يعطي بعض المزايا في التنقل التبعية على تخصيص مستوى واحد.

فيما يلي إحصائيات مستودعات الحزمة المركزية لـ Java / JS / PHP :

https://mvnrepository.com/repos/central - 3 358 578 جرة مفهرسة
https://www.npmjs.com/ - حزم 879 459
https://packagist.org/statistics - 207 560 حزمة (1،472،944 إصدار)

على الأرجح بالنسبة إلى maven يتم أخذ جميع إصدارات الوحدات في الحسبان في الإحصاءات ، بينما تؤخذ الوحدات النمطية نفسها في الاعتبار في npm composer .

ما هو مساحة الاسم ل؟

الإجابة الرئيسية هي منع التعارضات بين عناصر الكود المختلفة (الثوابت ، الدوال ، الفئات ، ...) التي لها نفس الاسم ولكن في وحدات نمطية مختلفة. مساحات أسماء بايثون تتعامل بنجاح مع هذا. لكنني ما زلت أحمل "مساحة الاسم" هنا بعلامات اقتباس ، لأن في جوهرها ، هو أقرب إلى النطاق .

تتيح مساحة الاسم وفقًا لإصدارات Java ( package ) و PHP ( namespace ) ، أولاً وقبل كل شيء ، معالجة عنصر شفرة محدد بشكل لا لبس فيه في المجتمع الكلي. وهذه خاصية خاصة بمساحة الاسم (التجميع المنطقي) التي تجعل من الممكن إنشاء أنظمة برامج أكثر تعقيدًا من خلال مجموعات أقل من المطورين.

معالجة عناصر البرنامج

في PHP فئة \Doctrine\DBAL\Schema\Column بشكل فريد ، \Doctrine\DBAL\Schema\Column النظر عن كيفية توصيل الكود المصدري بالمشروع. يمكن IDE تشكيل هذا العنوان بسهولة. في PhpStorm ، يتم ذلك مثل هذا (انقر بزر الماوس الأيمن فوق عنصر رمز):

يتم فقد نفس PhpStorm إذا قمت بتطبيق تقنية مشابهة لرمز JS (حيث لا توجد مساحة اسم). دعنا نحاول تكوين عنوان الرابط الخاص بوظيفة query JS بهذه الطريقة:

الإخراج هو module.query ، وهي ليست مفيدة بما فيه الكفاية.

لمعالجة وظيفة query في الوثائق (المراسلات ، تعقب الأخطاء ، وما إلى ذلك) ، يجب عليك الرجوع إلى سطر معين من التعليمات البرمجية في الملف:

النتيجة: ./node_modules/express/lib/middleware/query.js:25

بالطبع ، عند تغيير عدد الخطوط في ملف أو نقل / إعادة تسمية ملف ، سيكون لدينا في الوثائق عنوان قديم لعنصر البرنامج الذي يهمنا.

وبالتالي ، فإن استخدام مساحة الاسم يسمح للارتباطات بعناصر مختلفة من رمز المشروع أن تظل ذات صلة لفترة أطول بكثير من الارتباطات بسطر في ملف.

الكشف عن الإصدارات المتضاربة من التعليمات البرمجية

لا يمكن تطوير التطبيقات المعقدة الحديثة بدون مديري التبعية ( npm ، composer ، npm ، ...). في الوقت نفسه ، تقوم التبعيات الخاصة بنا بسحب التبعيات الخاصة بها ، والتي تسحب خاصة بها ، وما إلى ذلك ، مما قد يؤدي إلى تعارض في الإصدار لنفس الحزمة التي يتم سحبها عبر تبعيات مختلفة ( jar hell ).

في JS هذا لا يحدث بسبب عدم وجود مساحة الاسم. لقد واجهت نفسي موقفًا عندما Magento عدد الإصدارات المختلفة من مكتبة jQuery التي تم تحميلها من قبلهم 5-6 عند تثبيت وحدات إضافية في Magento . من ناحية ، يمنح مثل هذا السلوك مزيدًا من الحرية للمطورين بأنفسهم ، من ناحية أخرى - المزيد من الحرية تفرض مطالب أكثر على المؤهلات. حسنًا ، البحث عن أخطاء في مثل هذا المعكرونة متعددة الإصدارات من التبعيات - المؤهلات هي ترتيب أو اثنين أعلى من مؤهلات إنشاء هذه الأخطاء ذاتها.

إن استخدام مساحة الاسم في PHP يجعل من السهل اكتشاف مثل هذه التعارضات على مستوى IDE (على سبيل المثال ، قمت بإنشاء ملف ثانٍ مع نسخة مكررة من الفئة داخل):

وبالتالي ، فإن مهمة الكشف عن عناصر الكود المكررة في المشروع تصبح سهلة للغاية.

رمز بدء التشغيل

spl_autoload_register وظيفة spl_autoload_register في PHP للمطور عدم إزعاج المكان الذي توجد به الملفات مع مصادر فصوله بالضبط. في أي مشروع ، يمكنك تجاوز هذه الوظيفة وتنفيذ خوارزمية تحميل البرنامج النصي الخاصة بك حسب اسم الفئة. بدون استخدام مساحة الاسم ، كان من الضروري كتابة أسماء مجعدة تمامًا للفصول لضمان تفردها داخل مشروع معقد (خاصة مع مراعاة مكتبات الأطراف الثالثة). في 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 محمل ./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 عند تكوين المشروع ، بإنشاء خريطة لتركيب التسلسل الهرمي المنطقي للفئات على نظام الملفات. تلعب مساحات الأسماء دورًا مهمًا في هذا التراكب.

لتقييم هذا الدور ، يكفي محاولة تقسيم وحدة npm إلى عدة وحدات أصغر وإعادة إنشاء مشروعك لاستخدام وحدتين جديدتين بدلاً من واحدة كبيرة. بالمناسبة ، قد يؤدي وجود فئات في ES6 وعدم وجود مساحة اسم بمعنى التجميع المنطقي للرمز إلى ظهور أسماء مشابهة لتلك الموجودة في Zend1 ( Module_Path_To_Class ) في مشاريع ES6 الكبيرة.

IoC

معرف الكائنات في حاويات IoC عبارة عن سلسلة (على الأقل في PHP ). في أمثلة بسيطة ، تكون معرفات مثل dbAdapter و serviceB و serviceB ، وما إلى ذلك مقبولة تمامًا. ولكن كلما زاد حجم المشروع ، زاد صعوبة searchFilterList مكان إنشاء الكائن ذي المعرف ، على سبيل المثال ، searchFilterList وأين يتم استخدامه. المخرج المنطقي هو استخدام أسماء الفئات كمعرفات للكائنات. في هذه الحالة ، يصبح منطق إنشاء كائنات بواسطة الحاوية قابلاً للتنبؤ ، ويتم تحديد الكود المصدر وأماكن الاستخدام بشكل أساسي بواسطة IDE. تسمح لك مساحة الاسم بتنظيم جميع فئات المشروع في بنية منطقية واحدة واستخدام المسارات المناسبة عند إنشاء كائنات بحاوية.

ملخص

في ضوء ما تقدم ، أعتقد أن لغات البرمجة التي تستخدم مساحات الأسماء أصلاً لهيكلة الكود المصدري باستخدام تجميع منطقي لعناصرها تسمح لك بإنشاء تطبيقات أكثر تعقيدًا بتكلفة أقل من اللغات التي ليس لديها تجميع منطقي. وفقًا لذلك ، لا يمكن للمطورين الذين لديهم نفس المؤهلات في JavaScript / Python / C / .... تحقيق أقصى تعقيد للتطبيقات التي يمكن إنشاؤها في Java / PHP / C++ / ...