متى يكون لدينا أي استخدام عملي لمساحات الأسماء الهرمية في لغة C++؟
https://stackoverflow.com/questions/117110
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
أستطيع أن أفهم استخدام مستوى واحد من مساحات الأسماء.لكن 3 مستويات من مساحات الأسماء.يبدو مجنونا.هل هناك أي فائدة عملية لذلك؟أم أنها مجرد فكرة خاطئة؟
المحلول
إن لمساحات الأسماء الهرمية فائدة من حيث أنها تسمح بتعريفات أكثر دقة بشكل تدريجي.من المؤكد أن مزودًا واحدًا قد ينتج فئتين بنفس الاسم.غالبًا ما يشغل المستوى الأول اسم الشركة، ويحدد المستوى الثاني المنتج، أما المستوى الثالث (وربما أكثر) فيوفر المجال.
هناك أيضًا استخدامات أخرى لفصل مساحة الاسم.أحد المواقف الشائعة هو وضع الفئات الأساسية لنمط المصنع في مساحة الاسم الخاصة به ثم اشتقاق المصانع في مساحات الأسماء الخاصة بها بواسطة الموفر.على سبيل المثال System.Data, System.Data.SqlClient و System.Data.OleDbClient.
نصائح أخرى
ومن الواضح أنها مسألة رأي.لكن الأمر يتلخص حقًا في التنظيم.على سبيل المثال، لدي مشروع يحتوي على واجهة برمجة تطبيقات مكون إضافي تحتوي على وظائف/كائنات تبدو كما يلي:
plugins::v1::function
عند طرح الإصدار 2.0، سيتم وضعها في مساحة الاسم الفرعية v2.أخطط لإهمال أعضاء الإصدار الأول فقط ولكن لا أزيلهم مطلقًا، وهو ما من شأنه أن يدعم التوافق مع الإصدارات السابقة بشكل جيد في المستقبل.وهذا مجرد مثال واحد على الاستخدام "العاقل".أتصور أن بعض الناس سيختلفون، لكن كما قلت، إنها مسألة رأي.
سوف تحتاجها قواعد التعليمات البرمجية الكبيرة.انظر إلى التعزيز على سبيل المثال.لا أعتقد أن أي شخص قد يطلق على رمز التعزيز اسم "مجنون".
إذا أخذت في الاعتبار حقيقة أنه في أي مستوى من التسلسل الهرمي، لا يمكن للأشخاص فهم سوى مكان ما بشكل تقريبي جدًا في حدود 10 عناصر، فإن المستويين يمنحك 100 فقط كحد أقصى.سيحتاج المشروع الكبير بدرجة كافية إلى المزيد، لذلك يمكن أن ينتهي به الأمر بسهولة إلى عمق 3 مستويات.
أنا أعمل على تطبيق XXX في شركتي yyy، وأقوم بكتابة نظام فرعي لواجهة المستخدم الرسومية.لذلك أستخدم yyy::xxx::gui كمساحة الاسم الخاصة بي.
يمكنك بسهولة أن تجد نفسك في موقف تحتاج فيه إلى أكثر من مستوى واحد.على سبيل المثال، تمتلك شركتك مساحة اسم عملاقة لجميع التعليمات البرمجية الخاصة بها لفصلها عن التعليمات البرمجية الخاصة بطرف ثالث، وأنت تقوم بكتابة مكتبة تريد وضعها في مساحة الاسم الخاصة بها.بشكل عام، عندما يكون لديك نظام كبير جدًا ومعقد، ومقسم بشكل هرمي، فمن المعقول استخدام عدة مستويات لمساحة الاسم.
ذلك يعتمد على احتياجاتك وأسلوب البرمجة.ولكن من فوائد namespace هو المساعدة في تقسيم مساحة الاسم (وبالتالي الاسم).مع مساحة اسم واحدة، كلما زاد حجم مشروعك وتعقيده، تزداد أيضًا احتمالية تضارب الأسماء.
إذا كنت تكتب تعليمات برمجية بغرض مشاركتها أو إعادة استخدامها، يصبح هذا الأمر أكثر أهمية.
أنا أوافق على التطبيقات.معظم الأشخاص الذين يستخدمون مستويات متعددة من مساحات الأسماء (في تجربتي) يأتون من خلفية Java أو .NET حيث يكون التشويش أقل بكثير.أجد أن بادئات الفئة الجيدة يمكن أن تحل محل مستويات متعددة من مساحات الأسماء.
لكنني رأيت استخدامًا جيدًا لمستويات مساحة الاسم المتعددة في التعزيز (والمكتبات الأخرى).كل شيء موجود في مساحة الاسم المعززة، ولكن يُسمح للمكتبات (المشجعة؟) بأن تكون في مساحة الاسم الخاصة بها.على سبيل المثال - مساحة الاسم Boost::this_thread.يسمح بأشياء مثل...
boost::this_thread::get_id()
boost::this_thread::interruption_requested()
"this_thread" هو مجرد مساحة اسم لمجموعة من الوظائف المجانية.يمكنك أن تفعل الشيء نفسه مع فئة ووظائف ثابتة (أي.طريقة Java لتعريف وظيفة حرة)، ولكن لماذا تفعل شيئًا غير طبيعي عندما يكون لدى اللغة طريقة طبيعية للقيام بذلك؟
ما عليك سوى إلقاء نظرة على مكتبة الفئة الأساسية .Net لرؤية التسلسل الهرمي لمساحة الاسم الذي تم استخدامه بشكل جيد.يمتد الأمر إلى أربعة أو خمسة مستويات في أماكن قليلة، ولكن في الغالب يكون هناك مستويين أو ثلاثة فقط، والتنظيم جيد جدًا للعثور على الأشياء.
كلما كانت قاعدة التعليمات البرمجية أكبر، زادت الحاجة إلى مساحات الأسماء الهرمية.عندما يكبر مشروعك أكثر فأكثر، تجد أنك بحاجة إلى تقسيمه بطرق لتسهيل العثور على الأشياء.
على سبيل المثال، نستخدم حاليًا تسلسلًا هرميًا من مستويين.لكن بعض الأجزاء الأكبر التي نتحدث عنها الآن هي تقسيمها إلى 3 مستويات.
