2009-01-10 13 views
7

क्या अंगूठे का एक सामान्य नियम है कि वस्तुओं को एक नए नाम स्थान में आगे वर्गीकृत किए जाने से पहले किसी दिए गए नाम स्थान पर कितने वर्ग, इंटरफेस इत्यादि में जाना चाहिए? एक सर्वोत्तम अभ्यास या एक समुदाय वरीयता की तरह? या यह सब व्यक्तिगत वरीयता है?अंगूठे का नामस्थान नियम

namespace: MyExample.Namespace 
interface1 
interface2 
interface3 
interface4 
interface5 
interface6 
interface7 
interface8 
interface9 

या

namespace: MyExample.Namespace.Group1 
interface1 
interface2 
interface3 
namespace: MyExample.Namespace.Group2 
interface4 
interface5 
interface6 
namespace: MyExample.Namespace.Group3 
interface7 
interface8 
interface9 

उत्तर

4

मैंने किसी भी विश्वसनीय स्रोत पर अंगूठे का कोई नियम नहीं देखा है, लेकिन कुछ सामान्य प्राथमिकताओं के साथ काम करते समय मैंने कुछ सामान्य प्राथमिकताओं को देखा है। ऐसी कुछ चीजें हैं जो आपको नामस्थान बनाने में मदद करती हैं। वर्ग

  • की

    1. डोमेन यह एक वर्ग या एक अंतरफलक है (मैंने देखा है कुछ डेवलपर्स ShopApp.Model.Interfaces तरह नामस्थान पसंद करते हैं)। यदि आपका इंटरफेस कुछ सेवा या डेटा अनुबंध है तो वास्तव में अच्छा काम करता है।
    2. नामस्थान नहीं हैं जो बहुत गहरे हैं, 3 (।) पर्याप्त है। इससे भी ज्यादा परेशान हो सकता है।
    3. नामस्थान को पुनर्गठित करने के लिए खुले रहें यदि किसी भी समय आपको लगता है कि यह अजीब या प्रबंधित करने में मुश्किल हो गया है।
    4. इसके लिए नामस्थान बनाएं न कि।

    हैप्पी कोडिंग !!!

  • +0

    के वास्तविक उपयोग पर जोर देने के लिए अच्छा जवाब है। ध्यान में रखना एक और बात यह है कि यदि आप मौजूदा पुस्तकालय पर काम कर रहे हैं तो # 4 समस्याग्रस्त हो सकता है - इसलिए सुनिश्चित करें कि अगर आपको मौका मिलता है तो आपको पहली बार सही लगता है। ;) –

    0

    यह आम तौर पर बुरा रूप माना एक नाम स्थान में कक्षाओं की एक छोटी संख्या के लिए किया गया है। मैंने हमेशा इस तथ्य को जिम्मेदार ठहराया है कि कई नामस्थान भ्रम पैदा करते हैं।

    मैं सुझाव दूंगा कि आप कक्षाओं को लॉजिकल नेमस्पेस में यथासंभव उचित और व्यावहारिक रूप से तोड़ दें। हालांकि यदि आप प्रत्येक नामस्थान में केवल एक या दो कक्षाओं के साथ समाप्त होते हैं तो आप बहुत अधिक फ्रैक्चरिंग कर सकते हैं और समेकन के बारे में सोचना चाहिए।

    +1

    "आम तौर पर खराब रूप माना जाता है" - किसके द्वारा? यह बहुत विवादास्पद लगता है और बिल्कुल सामान्य नहीं। मैंने कभी यह नहीं सुना है। –

    +0

    यह कुछ FxCop हमेशा शिकायत करता है - यह मुझे बहुत पीछे है मुझे मुझे वापस लेना है :) –

    +0

    हालांकि माइक्रोसॉफ्ट सामान्यता नहीं है, खासकर नामस्थानों के बहुत सामान्य क्षेत्र में नहीं; लगभग सभी प्रोग्रामिंग भाषा माइक्रोसॉफ्ट द्वारा नहीं हैं; आईएमएचओ, नामस्थान के अंदर कक्षाओं की संख्या को इसके अस्तित्व को न्यायसंगत नहीं ठहराया जाना चाहिए, लेकिन अन्य कारण –

    2

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

    2

    यदि लाइब्रेरी या मॉड्यूल का निर्माण करना आम तौर पर केवल एक नामस्थान का उपयोग करना बेहतर होता है, क्योंकि नेमस्पेस का प्राथमिक कार्य नाम टकराव से बचने के लिए है और आपके पास नियंत्रण है कि कक्षाओं और इंटरफेस को कौन से नाम सौंपा गया है।

    +1

    +1 हैं जो नेमस्पेस – Perpetualcoder

    1

    मैं तर्क दूंगा कि नामस्थान पदानुक्रम केवल मॉडल/एपीआई के डिजाइन और पदानुक्रम के विचारों से गौर्न किया जाना चाहिए।

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

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

    दूसरी तरफ, मुझे नामस्थान के लिए केवल एक बहुत ही विशेष वर्ग, या शायद केवल एक बहुत ही छोटे प्रकार के सेट के लिए यह उचित लगता है, जिसमें से कोई कार्य को एन्कोड करता है और अन्य एक एपीआई (अपवाद, तर्क के लिए enums ...)।

    उदाहरण के तौर पर, System.Text.RegularExpressions (.NET में) लें। अनुमोदित, एक वर्ग से थोड़ा अधिक, लेकिन केवल बस।