पुस्तकालयों के लिए सी # नेमस्पेस और क्लास नामकरण सम्मेलन

Question

मैं C # में विभिन्न छोटे उपयोगिता कार्यों के साथ पुस्तकालयों का निर्माण कर रहा हूं, और एक नाम स्थान और वर्ग नामकरण सम्मेलन पर निर्णय लेने की कोशिश कर रहा हूं। मेरा वर्तमान संगठन इस प्रकार है:

Company
Company.TextUtils
    public class TextUtils {...}
Company.MathsUtils
    public class MathsUtils {...}
    public class ArbitraryPrecisionNumber {...}
    public class MathsNotation {...}
Company.SIUnits
    public enum SISuffixes {...}
    public class SIUnits {...}

क्या यह नामस्थान और वर्गों को व्यवस्थित करने का एक अच्छा तरीका है, या कोई बेहतर तरीका है? विशेष रूप से ऐसा लगता है कि नाम स्थान और वर्ग नाम (जैसे Company.TextUtilsनाम स्थान और TextUtilsवर्ग) में समान नाम होने से सिर्फ दोहराव होता है और पता चलता है कि योजना बेहतर हो सकती है।

Comments

martinfowler.com/bliki/TwoHardThings.html

— richzilla

Microsoft दिशानिर्देश, एनमों के लिए एकवचन नामों की अनुशंसा करते हैं (इसलिए SISuffixइसके बजाय SISuffixes), और मुझे लगता है कि एकवचन बेहतर पढ़ता है। "प्रत्यय ए" के Suffix.A रूप में पढ़ता है । इसके अलावा, मैं आमतौर पर पदानुक्रम में एक स्तर से नाम दोहराने से बचता हूं। इसके बजाय Company.SIUnits.SISuffixes, मैं झुकना चाहूंगा Company.SI.SuffixऔरCompany.SI.Unit

— हैरिसन पाइन

@richzilla thecodelesscode.com/case/220

— टिन मैन

Answer 1

यह निर्धारित करना बहुत मुश्किल है कि आपके नामकरण की रणनीति आपके कोड के बाकी हिस्सों से अलगाव में कितनी प्रभावी है।

नाम स्थान को कुछ विचार देना चाहिए जहां यह आपके कोडबेस की व्यापक संरचना में फिट बैठता है, और वर्ग नाम आमतौर पर वर्णन करेगा कि यह उस क्षेत्र के भीतर किस प्रकार की कार्यक्षमता या अवधारणा का प्रतिनिधित्व करता है।

अपने विशिष्ट उदाहरण में, अलग से, यदि आपके पास बहुत अधिक 'यूटिल' प्रकार की कक्षाएं होने की संभावना है, तो मैं उन्हें इसके तहत रखने पर विचार करूंगा Company.Utils.Maths। इस तरह यदि आपको कार्यक्षमता को जोड़ने की आवश्यकता है जो कि कई उपयोगिता क्षेत्रों में आम है, तो आपके पास पहले से ही है। इसके लिए एक प्राकृतिक स्थान।

Comments

वह एक अच्छा विचार लगता है। चिंता को बहुत अधिक रोकें, बस इसे "Company.Util" में पूरा करें।

— उपयोगकर्ता

Answer 2

एक अच्छा दस्तावेज़ है जिसमें बहुत सारे नियम हैं जिनका आपको Microsoft: फ्रेमवर्क डिज़ाइन दिशानिर्देशों के अनुरूप होना चाहिए ।

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

Comments

नामस्थान दिशा-निर्देशों का सीधा लिंक: msdn.microsoft.com/en-us/library/ms229026(v=vs.110).aspx

— पगोटी

जो संयोग से या इस विषय पर एक महान पुस्तक का एक ही नाम भी नहीं है, यह भी माइक्रोसॉफ्ट के लोगों द्वारा लिखा गया है, जिन्होंने डॉटनेट ढांचे के निर्माण में भाग लिया, उन्होंने जो कुछ किया उसके बारे में कई टिप्पणियों के साथ उन्होंने सही किया और जहां उन्हें चीजें गलत मिलीं। वर्थ पढ़ें: amazon.com/Framework-Design-Guidelines-Conventions-Lbooks/dp/…

— Machado

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

— मचाडो

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

— जॉन

Microsoft की रूपरेखा डिज़ाइन दिशा-निर्देश अत्यधिक संदेहास्पद हैं, इसमें .NET कथन कैसे काम करता है, के बारे में गलत कथन शामिल हैं, और बहुत बार Microsoft द्वारा इसका अनुसरण नहीं किया जाता है। उनके नामकरण के दिशा-निर्देश अच्छे हैं, लेकिन मैं समग्र दिशानिर्देशों को एक बयान के साथ जोड़ने से बचूंगा कि "आपको उनका पालन करना चाहिए"।

— कार्ल लेथ

Answer 3

जब से मैंने C # या .NET इकोसिस्टम के साथ काम किया है, तब से कुछ समय हो गया है, इसलिए मैं यह नहीं कह सकता कि वर्तमान अनुशंसित सर्वोत्तम अभ्यास क्या हैं। मैं आपके नामों को इस तरह बदलने की सलाह दूंगा:

Company
Company.Text
    public class TextUtils {...}
Company.Math
    public class MathUtils {...}
    public class ArbitraryPrecisionNumber {...}
    public class MathsNotation {...}
Company.SI
    public enum SISuffixes {...}
    public class SIUnits {...}

मैंने यहाँ क्या किया है नामस्थान नामों से "Utils" हटा दें। मुझे लगता है कि "Util" एक नामस्थान में नहीं होना चाहिए, क्योंकि Company.Textनाम स्थान में एक दिन ऐसी कक्षाएं हो सकती हैं जो पाठ उपयोगिता वर्ग नहीं हैं। Company.Mathनाम स्थान पहले से ही शामिल है ArbitraryPrecisionNumberजो एक "उपयोगिता" होने लगते हैं नहीं करता है।

नामपट्ट से "यूटिल" को हटाने से किसी भी भ्रम की स्थिति साफ हो जाती है जो एक ही नाम के साथ दो चीजें हो सकती हैं (जैसा कि रॉबर्ट के जवाब में वर्णित है: /software//a/340440-13156 )

एक और तरीका जिससे आप कोड व्यवस्थित कर सकते हैं:

Company
Company.Util
    public class TextUtils {...}
    public class MathUtils {...}
Company.Math
    public class ArbitraryPrecisionNumber {...}
    public class MathsNotation {...}
Company.SI
    public enum SISuffixes {...}
    public class SIUnits {...}

इस स्थिति में, सभी उपयोगिता वर्ग समान नामस्थान में रहते हैं। Company.Textकेवल उपयोगिता वर्ग होने के कारण कोई और नाम स्थान नहीं है ।

व्यक्तिगत रूप से, मुझे पहला विकल्प थोड़ा और स्पष्ट लगता है।

Answer 4

नामस्थान और उसके अंदर के वर्ग के लिए एक ही नाम का उपयोग करना समस्याग्रस्त है।

• यदि नाम स्थान में एक से अधिक वर्ग होते हैं, तो अन्य कक्षाओं को क्यों रखा जाएगा? यह सही नहीं लगता है, क्योंकि नामस्थान के नाम का लक्ष्य इसके भीतर सभी वर्गों का वर्णन करना है, न कि केवल एक। उदाहरण के लिए, अगर आपके पास JsonSerialization, BinarySerializationऔर XmlSerializationएक नाम स्थान में कक्षाएं, यह भावना आपके नाम स्थान नाम के लिए होगा XmlSerialization?

  आमतौर पर क्या होता है कि किसी मौजूदा नामस्थान से एक वर्ग के निष्कर्षण के कारण, या कई वर्गों या अन्य पुनर्गठन के बीच विलय के कारण, आप खुद को एक बड़े वर्ग वाले नाम स्थान के साथ पाते हैं ; उत्तरोत्तर, छोटे वर्गों को वहां रखा जाता है क्योंकि वे मूल वर्ग से थोड़े संबंधित होते हैं। उदाहरण के लिए, एक नामस्थान LogParserमें एक एकल वर्ग हो सकता है LogParser, और फिर कोई व्यक्ति डालता है LogConverter, क्योंकि यह पार्सर से काफी संबंधित है, फिर LogSearcher, आदि। यहाँ समस्या यह है कि नामस्थान का नाम नहीं बदला गया था: जैसे ही LogConverterजोड़ा गया था, नाम को LogsProcessingया, बस, को बदल दिया जाना चाहिए था Logs।

• यदि नामस्थान में केवल एक वर्ग होता है, तो यह कोड संगठन के भीतर किसी समस्या का संकेत हो सकता है।

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

  यहां तक ​​कि अगर आपके नाम स्थान में केवल एक ही वर्ग है, तो आमतौर पर कक्षा का नामकरण करते समय अधिक विशिष्ट होने का एक तरीका है, और नाम स्थान का नामकरण करते समय अधिक सामान्य है। एक ऐसे अनुप्रयोग की कल्पना करें, जो अन्य बातों के साथ-साथ, ABC प्रारूप में लिखी गई फ़ाइलों को DEF प्रारूप में परिवर्तित करना चाहिए। रूपांतरण को व्यावसायिक वस्तुओं से / के लिए किसी भी डीरियलाइज़ेशन / क्रमांकन की आवश्यकता नहीं होती है, और नियमित अभिव्यक्तियों का एक गुच्छा लगाने से किया जाता है जो कि रूपांतरण वर्ग के भीतर रखे जाने के लिए पर्याप्त हैंAbcToDefConverter। सभी रूपांतरण तर्क लगभग दस अन्योन्याश्रित विधियों में लगभग 80 एलएलओसी लेते हैं- ऐसी स्थिति की तरह प्रतीत होता है जहाँ न तो मौजूदा वर्ग को विभाजित करने की कोई आवश्यकता है, न ही अतिरिक्त कक्षाएं बनाने की। चूंकि आवेदन के शेष भाग का रूपांतरणों से कोई लेना-देना नहीं है, इसलिए वर्ग को अन्य नामों के साथ अस्तित्वगत नामस्थानों में वर्गीकृत नहीं किया जा सकता है। तो एक नेमस्पेस नाम बनाता है AbcToDefConverter। जबकि इसमें कुछ भी गलत नहीं है, एक अधिक सामान्य नाम का उपयोग भी कर सकता है, जैसे कि Converters। पायथन जैसी भाषाओं में, जहां छोटे नामों को प्राथमिकता दी जाती है और पुनरावृत्ति को फेंक दिया जाता है, यह भी बन सकता है converters.Abc_To_Def।

इसलिए, जिन वर्गों में वे सम्‍मिलित हैं, उनके नामनामों के लिए अलग-अलग नामों का उपयोग करें। एक वर्ग के नाम से संकेत मिलता है कि वर्ग क्या कर रहा है, जबकि नाम स्थान का नाम उजागर करना चाहिए कि सभी वर्गों में क्या सामान्य है।

---

वैसे, उपयोगिता वर्ग प्रकृति द्वारा गलत हैं: कुछ विशिष्ट, जैसे कि मनमानी परिशुद्धता अंकगणित, के बजाय वे सब कुछ शामिल करते हैं जो अन्य वर्गों में अपना रास्ता नहीं ढूंढते हैं । यह केवल Miscellaneousएक डेस्कटॉप पर एक निर्देशिका के रूप में बुरा नामकरण है - ऐसा कुछ जो संगठन की कमी का संकेत है।

नामकरण एक कारण के लिए मौजूद है: बाद में सामान खोजने की आवश्यकता होने पर अपने जीवन को आसान बनाने के लिए। आप जानते हैं कि यदि आपको एक चार्ट बनाने की आवश्यकता है, तो आप "चार्ट" या "प्लॉट" खोजने की कोशिश कर सकते हैं। जब आपको किसी एप्लिकेशन को चालान बनाने के तरीके को बदलने की आवश्यकता होती है, तो आप "चालान [ई / आईएनजी]" या "बिल" की खोज करेंगे। इसी तरह, एक ऐसे मामले की कल्पना करने की कोशिश करें, जहाँ आप खुद से कहेंगे: "एचएम, यह सुविधा शायद मिसकैर में मिलनी चाहिए"। मैं नहीं कर सकता।

.NET फ्रेमवर्क को देखें। उन वर्गों के अधिकांश उपयोगिता वर्ग नहीं हैं? मेरा मतलब है, उनके पास व्यापार डोमेन के साथ कुछ चीजें हैं। अगर मैं एक वित्तीय ऐप, या एक ई-कॉमर्स वेबसाइट, या अगले जनरल एजुकेशन प्लेटफॉर्म पर काम करता हूं, तो एक्सएमएल को सीरीज़ करना या फाइलें पढ़ना या एसक्यूएल क्वेरी करना या लेनदेन करना सभी उपयोगी सामान हैं। हालांकि, उन्हें बुलाया नहीं गया है , UtilitySerializationया UtilityTransactionवे Utilityनाम स्थान में नहीं हैं । उनके पास उचित नाम हैं, जो संभव होने पर (और आसान, धन्यवाद .NET डेवलपर्स!) उन्हें मेरी आवश्यकता होने पर खोजने के लिए बनाते हैं।

आपकी कक्षाओं के लिए वही आता है जिसे आप आमतौर पर अपने ऐप्स में पुनः उपयोग करते हैं। वे उपयोगिता वर्ग नहीं हैं। वे कक्षाएं हैं जो कुछ चीजें करते हैं, और जो चीजें वे करते हैं वे वास्तव में कक्षाओं के नाम होने चाहिए।

कल्पना कीजिए कि आपने कुछ कोड बनाए हैं जो इकाइयों और इकाइयों के रूपांतरण से संबंधित हैं। आप इसे नाम दे सकते हैं Utilityऔर अपने सहयोगियों से नफरत कर सकते हैं; या आप इसे नाम दे सकते हैं Unitsऔर UnitsConversion।

Comments

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

— FrustratedWithFormsDesigner

मैं आपसे सहमत हूं, लेकिन आप एक विकल्प के रूप में क्या सुझाव देते हैं?

— उपयोगकर्ता

आई

— शैल

मैंने सबसे लंबे समय तक "बर्तन" पुस्तकालय बनाने में देरी की, लेकिन आखिरकार आपको बस इसमें देना होगा। विकल्प में DLL है जिसमें कोड की लगभग 3 पंक्तियाँ शामिल हैं, जो सिर्फ बोझिल है (और निर्भरता नोड की गड़बड़ी की याद दिलाती है। js) ), या हर एक वर्ग के लिए अपनी उपयोगिता विधियों को कॉपी और पेस्ट करना, जिनकी उन्हें आवश्यकता हो सकती है ("यादृच्छिक तरीकों का संग्रह" करने से बचने के लिए)। आईएमओ अंत में यह एक आवश्यक बुराई है।

— मत्ती विर्ककुनेन

@FrustratedWithFormsDesigner: बस ... Math? मैं यह नहीं देखता कि Utilityहर चीज में प्रत्यय जोड़ना हमारे जीवन को कैसे आसान बना देगा। .NET की System.Math.Min()विधि का उपयोग करते समय , क्या आप वास्तव में SystemUtility.MathUtility.Min()इसके बजाय लिखना पसंद करेंगे ? सभी मामलों में, मैंने अपने उत्तर को बहुत अधिक संपादित किया है, इसलिए इसे अभी स्पष्ट होना चाहिए।

— आर्सेनी मूरज़ेंको