क्या सभी enums को एक ही स्थान पर रखना अच्छा विचार है?

Question

जब मैं कक्षा पुस्तकालय का निर्माण कर रहा हूं, तो आम तौर पर असेंबली में उपयोग की जाने वाली सभी enums को पकड़ने के लिए मैं एक फ़ाइल Enums.cs बनाता हूं। यहां एक उदाहरण दिया गया है:

namespace MyNamespace 
{ 
    public enum Colors 
    { 
     Red, 
     Green, 
     Blue 
    } 
    public enum Shapes 
    { 
     Circle, 
     Square, 
     Triangle 
    } 
} 

यह मेरे सभी enums को कोड में आसानी से व्यवस्थित, व्यवस्थित और आसानी से उपयोग करने में आसान बनाता है।

मुझे आश्चर्य है कि क्या कोई कारण है कि यह इतना अच्छा विचार नहीं होगा?

Answer 1

आमतौर पर प्रकार के बजाय मॉड्यूलरिटी द्वारा परिभाषाओं की व्यवस्था करना बेहतर होता है।

Answer 2

हमारे पास आम तौर पर एक संपूर्ण परियोजना है, असेंबली जिसमें हमारे सभी कॉन्स्टेंट, एनम्स और सहायक तरीके हैं।

तो हाँ, मैं उन्हें एक केंद्रीय, आसानी से सुलभ स्थान पर रखने की सिफारिश करता हूं।

यह आपको परिपत्र संदर्भों से बचने की कोशिश कर, अन्य असेंबली से असेंबली तक आसानी से पहुंचने की अनुमति देगा।

Answer 3

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

आपके दृष्टिकोण में मुख्य नकारात्मकता उत्पन्न होती है यदि आपके पास आपके प्रोजेक्ट में परिभाषित कई एम्स हैं - कि "एक फ़ाइल" काफी बड़ी हो सकती है।

हालांकि, संकलित आईएल में कोई तकनीकी अंतर नहीं है। यह वास्तव में एक व्यक्तिगत, संगठनात्मक रणनीति का अधिक है।

Answer 4

मुझे लगता है कि यह इस बात पर निर्भर करता है कि वे किस कोड पर लागू होते हैं। यदि मैं किसी विशेष वर्ग में किसी फ़ंक्शन को देख रहा हूं, तो मैं अपेक्षा करता हूं कि संबंधित enums पास हो।

Answer 5

ठीक है, आप अपने सभी प्रतिनिधि प्रकारों, अपने सभी वर्गों, अपने सभी structs पर एक ही तर्क लागू कर सकते हैं।

कंपेलर को उनके महत्व के अनुसार चीजों को समूहीकृत करके, आप उन्हें के अर्थपूर्ण तरीके से समूहित करने का अवसर खो रहे हैं। संकलक पहले से ही जानता है कि भाषा में उनके अर्थ के अनुसार उनका इलाज कैसे करें।

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

Answer 6

मैं एक अधिक नामस्थान संगठन के लिए जाता हूं। विजुअल स्टूडियो किसी ऑब्जेक्ट की घोषणा पर नेविगेट करना बहुत आसान बनाता है। यह मुझे कुछ सामान्य ज्ञान नामस्थान के बजाय मेरे माईडाटा नेमस्पेस में डेटाबेस/डेटा एक्सेस से संबंधित एक enum रखने के लिए और अधिक समझ में आता है, मैं फ़ाइल नाम के बारे में कम ख्याल रख सकता हूं।

Answer 7

कुछ कोड-फ़ाइल नाम हैं जो तुरंत मेरे लिए लाल झंडा उठाते हैं। utils.cpp, helpers.vb (या इसी तरह) के साथ यदि मैं enums.cs देखता हूं तो मैं तुरंत पूछता हूं कि सॉफ़्टवेयर का एक टुकड़ा गणनाओं के साथ-साथ बढ़ रहा है या नहीं।

गणनाओं का उपयोग कम से कम किया जाना चाहिए और पत्ते (कम से कम प्रकार के युग्मित) प्रकारों के साथ घोषित किया जाना चाहिए जिनके साथ वे जुड़े हुए हैं।

अक्सर मैंने बड़ी प्रणालियों को देखा है जो साझा गणनाओं के कारण युग्मित हो गए हैं। बहुत लंबे समय से पहले सभी डेटाबेस प्राथमिक कुंजी को गणना करने के लिए उज्ज्वल विचार होगा।

Answer 8

मैं एक जावा developper हूँ लेकिन मुझे लगता है कि मैं यहाँ भी जवाब कर सकते हैं ...

मेरे लिए यह एक अच्छा विचार नहीं है। डैनियल ईरविकियर की तरह कहा कि आप कक्षाओं के लिए भी ऐसा ही कर सकते हैं ... आप अपने पूरे एप्लिकेशन को एक ही फाइल में कई आंतरिक कक्षाओं के साथ संभाल सकते हैं (मुझे लगता है कि जावा में सी # में आंतरिक कक्षाएं हो सकती हैं ...), लेकिन आप ' टी वैसे भी यह कर ...

और एक enum कुछ समय एक अधिक जटिल संरचना हो सकता है, यह गुण हो सकता है ...

एक (बहुत) जावा में सरल उदाहरण:

public enum JobPriority { 
    HIGH(5), 
    MEDIUM_HIGH(4), 
    MEDIUM(3), 
    MEDIUM_LOW(2), 
    LOW(1) 
    ; 
    private int level; 
    JobPriority(int level) { 
     this.level = level; 
    } 
    public int getLevel() { 
     return level; 
    } 
} 

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

तो यदि आपका आवेदन छोटा है और enum संरचना जटिल नहीं है, तो आप सभी को एक फ़ाइल में डाल सकते हैं।

लेकिन आप एक एनम नेमस्पेस (जावा में पैकेज) पर एकल फाइलों में जटिल enums डाल देंगे, और अपने आवेदन के प्रत्येक कार्यात्मक भाग के लिए आवश्यक होने पर एक enum नेमस्पेस बनाना होगा। सरल enums के लिए, किसी दिए गए नेमस्पेस के लिए एक सामान्य enum फ़ाइल में क्यों नहीं जोड़ना (आप एकाधिक आम enums फ़ाइलों हो सकता है)। डुनो अगर यह एक अच्छा अभ्यास है।

क्या यह वास्तव में आपके लिए कई enum फाइलों के लिए महत्वपूर्ण है? यदि आपको एक एनम खोजने की ज़रूरत है, तो आपका आईडीई शायद आपको आसानी से enums नहीं ढूंढने के लिए तेजी से कक्षा खोज प्रदान करता है? आप अपने सभी enums को xxxEnum.cs से अलग करने के लिए भी प्रत्यय कर सकते हैं (और उन्हें कक्षा के नाम * Enum द्वारा सभी को तेज़ी से भी ढूंढें)।

जावा वेबपैप में मैं (~ 2 मिलियन लाइन कोड, सैकड़ों enums) पर काम कर रहा हूं, हम आसानी से हमारे ग्रहण आईडीई में ctrl + shift + r + * Enum जैसे शॉर्टकट के साथ enums पा सकते हैं। यह सामान्य enum फाइलों की तुलना में बहुत तेज़ है :)