क्या आप लंबी स्विच/एनम घोषणाओं के भीतर क्षेत्रों का उपयोग करेंगे?

मैंने हाल ही में सी # कोड में 1,कथन और enum घोषणाओं को परिभाषित करने के लिए खुद को (हाँ, आवश्यकता) की आवश्यकता है, लेकिन मुझे आश्चर्य है कि लोगों को लगता है कि उन्हें तार्किक उपखंडों में विभाजित करने का सबसे अच्छा तरीका क्या है। मेरी स्थिति में, enum मानों और मामलों (जो enum मानों पर आधारित हैं) दोनों में स्पष्ट रूप से स्पष्ट समूह हैं, फिर भी मुझे कोड में इसे प्रतिबिंबित करने के बारे में कुछ अनिश्चितता है।क्या आप लंबी स्विच/एनम घोषणाओं के भीतर क्षेत्रों का उपयोग करेंगे?

ध्यान दें कि मेरे कोड में, मेरे पास 10 से 30 एनम मूल्य/मामलों के बीच लगभग 5 समूह हैं।

तीन थोड़ा समझदार विकल्प की परिकल्पना कर सकते हैं:

घोषणा (वैकल्पिक रिक्त लाइनों से विभाजित) के भीतर मामलों/enum सभी मान तार्किक समूहों के आसपास #region ब्लॉकों को परिभाषित करें।
प्रत्येक समूह नाम टिप्पणी से पहले एक खाली रेखा के साथ, प्रत्येक समूह को इसके नाम से टिप्पणी करें।
कुछ भी नहीं करें - बस स्विच/एनम को मामलों/मूल्यों की एक बड़ी सूची के रूप में छोड़ दें।

आप कौन सा पसंद करते हैं? क्या आप enums का इलाज करेंगे और अलग से स्विच करेंगे? (यह मेरे लिए थोड़ा अजीब प्रतीत होता है।) अब, मैं यह नहीं कहूंगा कि इस प्रश्न का कोई सही/गलत जवाब है, फिर भी मुझे यह देखने में काफी दिलचस्पी होगी कि विचारों का सामान्य ज्ञान क्या है।

नोट 1: यह स्थिति है जहाँ मैं संभवतः 50/100 + मूल्यों की एक लंबी enum घोषणा हो सकता है दुर्भाग्य से अपरिहार्य (और इसी तरह स्विच के साथ) है, के बाद से मैं एक lexer (tokeniser) लिखने का प्रयास कर रहा हूँ, और यह कई कारणों से सबसे उचित दृष्टिकोण प्रतीत होता है।

नोट 2: मैं पूरी तरह से पता है कि कई डुप्लिकेट सवाल पहले से ही है कि क्या (संरचना कक्षाएं, मुख्य रूप से के लिए) सामान्य कोड में क्षेत्रों का उपयोग करने के सवाल पर मौजूद हूँ, लेकिन मुझे लगता है कि मेरे सवाल यहाँ और अधिक विशिष्ट और hasn है अभी तक संबोधित नहीं किया गया है।

स्रोत

2009-06-26 Noldorin

अभी मेरा जवाब संपादित किया गया। उम्मीद है कि यह मदद करता है :) –

निश्चित रूप से, उन चीज़ों को क्षेत्र बनाएं। वे शायद ज्यादा नहीं बदलते हैं, और जब वे करते हैं, तो आप क्षेत्र का विस्तार कर सकते हैं, अपने बदलाव कर सकते हैं, इसे ध्वस्त कर सकते हैं, और बाकी फाइल पर जा सकते हैं।

वे एक कारण के लिए हैं, उन्हें अपने लाभ के लिए उपयोग करें।

स्रोत

2009-06-26 19:03:01

इस प्रश्न से पूछने से पहले यह मेरी सोच बहुत सुंदर रही है। मैं कुछ हद तक "बुराई" क्षेत्रों का अधिक उपयोग करने पर विचार करता हूं, लेकिन यह एक अपवाद प्रतीत होता है। – Noldorin

मैं इसे मामलों/मूल्यों की एक बड़ी सूची के रूप में छोड़ दूंगा।

स्रोत

2009-06-26 18:56:17

कारण यह है कि आप सामान्य रूप से क्षेत्रों को पसंद नहीं करते हैं, मैं इसे लेता हूं? (यह एक उचित बिंदु भी हो सकता है।) – Noldorin

+1 मुझे क्षेत्रों को उर्फ कोड obfuscation पसंद नहीं है। – kenny

मुझे सामान्य रूप से या इस विशिष्ट उदाहरण में क्षेत्रों को पसंद नहीं है :)। मैं वर्ग फ़ाइलों को ध्वस्त करने के लिए ctrl + m + o का उपयोग करना पसंद करता हूं। क्षेत्र मेरी मंशा तोड़ते हैं क्योंकि मैं कोड के बजाय क्षेत्र को देखता हूं। –

enums से छुटकारा पाएं और उन्हें वस्तुओं में बना दें। फिर आप अपनी ऑब्जेक्ट्स पर विधियों को कॉल कर सकते हैं और कोड अलग, रखरखाव योग्य और दुःस्वप्न नहीं रख सकते हैं।

बहुत कम मामले हैं जब आपको वास्तव में किसी ऑब्जेक्ट के बजाय एनम का उपयोग करने की आवश्यकता होती है और कोई भी लंबे स्विच स्टेटमेंट पसंद नहीं करता है।

स्रोत

2009-06-26 18:56:31

मेरा पहला नोट देखें। यह एक लेक्सर है (एक कंपाइलर के हिस्से के रूप में) मैं लिख रहा हूँ। मौजूदा कोड में मैंने देखा एकमात्र दृष्टिकोण एक enum का उपयोग करना है - हालांकि इन उदाहरणों को आम तौर पर केवल एक बहुत ही सरल व्याकरण के लिए परिभाषित किया जाता है, इसलिए वास्तव में किसी भी समूह की आवश्यकता नहीं होती है। – Noldorin

मुझे नहीं लगता कि मेरा जवाब बदलता है। स्रोत को देखे बिना, मुझे विश्वास करना है कि उन्हें मूल्य वस्तुओं में विभाजित किया जा सकता है। –

दुर्भाग्यवश, मुझे वास्तव में किसी प्रकार की डेटा संरचना के साथ मान निर्दिष्ट करने की आवश्यकता है। मुझे यह कहना चाहिए था कि enum lexer में एक "टोकन प्रकार" का प्रतिनिधित्व करता है, और एक टोकन संरचना के भीतर संग्रहीत किया जाना चाहिए। – Noldorin

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

स्रोत

2009-06-26 19:00:20 mkato

दिलचस्प सुझाव। मैं रणनीति पैटर्न से वास्तव में परिचित नहीं हूँ। क्या यह वास्तव में यहां प्रासंगिक है, इस मामले में कि मेरा enum टोकन प्रकारों का एक सेट प्रस्तुत करता है (और मैं इसे एक कंपाइलर के लिए लिख रहा हूं)? – Noldorin

मुझे रणनीति का उपयोग करने में बहुत अधिक समस्या नहीं दिख रही है। असल में, आप प्रत्येक केस ब्लॉक के अंदर तर्क करने के लिए जिम्मेदार कक्षाएं बनाते हैं। यह वह व्यक्ति है जो बड़ी कक्षा को चालू करता है (जिसने स्विच ब्लैकोक किया है) जो परिभाषित करता है कि कौन सा तर्क वर्ग इसका उपयोग करेगा। – mkato

आपके पास एक शब्दकोश < [your_enum_type], एक्शन> (या कार्रवाई के बजाय Func) या ऐसा कुछ भी हो सकता है (आपके कार्यों पर एक समान हस्ताक्षर है)।तो फिर तुम बजाय सकता है एक स्विच का उपयोग, के बजाय:

 switch (item) 
     { 
      case Enum1: func1(par1, par2) 
       break; 
      case Enum2: func2(par1, par2) 
       break; 
     }

आप की तरह कुछ हो सकता था:

public class MyClass 
{ 
    Dictionary<int, Action<int, int>> myDictionary; 
    //These could have only static methods also 
    Group1Object myObject1; 
    Group2Object myObject2; 

    public MyClass() 
    { 
     //Again, you wouldn't have to initialize if the functions in them were static 
     myObject1 = new Group1Object(); 
     myObject2 = new Group2Object(); 
     BuildMyDictionary(); 
    } 

    private Dictionary<int, Action<int, int>> BuildMyDictionary() 
    { 
     InsertGroup1Functions(); 
     InsertGroup2Functions(); 
     //... 
    } 

    private void InsertGroup2Functions() 
    { 
     myDictionary.Add(1, group2.AnAction2); 
     myDictionary.Add(2, group2.AnotherAction2); 
    } 

    private void InsertGroup1Functions() 
    { 
     myDictionary.Add(3, group1.AnAction1); 
     myDictionary.Add(4, group1.AnotherAction1); 
    } 


    public void DoStuff() 
    { 
     int t = 3; //Get it from wherever 
     //instead of switch 
     myDictionary[t](arg1, arg2); 
    } 
}

स्रोत

2009-06-26 19:09:08

इस विधि में निश्चित रूप से कई परिस्थितियों (विशेष रूप से लंबे मामले के ब्लॉक) में इसके फायदे हैं। हालांकि, मेरे लिए यह वास्तव में स्विच स्टेटमेंट मामलों को केवल एक शब्दकोश में आइटम जोड़ने की विधि में स्थानांतरित कर रहा है, और वास्तव में समूहबद्ध करने में सहायता नहीं करता है। – Noldorin

IMHO यह बिल्कुल समान नहीं है - यह उन तरीकों को अलग-अलग तरीकों से जोड़ने के लिए एक अच्छा तरीका है। यह आपको प्रतिनिधियों के माध्यम से अबास्ट्रक्शन का एक अतिरिक्त स्तर भी प्रदान करता है - आप अपने कोड में कहीं से भी किसी भी प्रतिनिधि को सूची में जोड़ सकते हैं। – Groo

@ सैमुएल: उदाहरण कोड जोड़ने के लिए धन्यवाद। दरअसल, जिस तरीके से आप विधियों में शब्दकोश प्रारंभिक विभाजन को विभाजित कर सकते हैं वह काफी फायदेमंद है। मैं अब इस समाधान को पसंद करना शुरू कर रहा हूं। :) – Noldorin

यहाँ लोग हैं, जो क्षेत्रों का उपयोग के लिए एक अच्छा शॉर्टकट है।

मैं ग्रहण और दृश्य स्टूडियो के बीच स्विच था जब मैं

Ctrl-M-M

दबाने और लो द्वारा वी.एस. में पूर्ण स्क्रीन पर जाने और निहारना करने की कोशिश की, इस क्षेत्र को बंद कर दिया और विस्तार किया!

स्रोत

2009-06-26 19:55:56

हाँ, कुछ आसान शॉर्टकट हैं, जो मुझे लगता है कि संभावित रूप से क्षेत्र होने से क्षेत्रों को उपद्रव से कम कर सकते हैं। :) – Noldorin

क्या आप लंबी स्विच/एनम घोषणाओं के भीतर क्षेत्रों का उपयोग करेंगे?

उत्तर

संबंधित मुद्दे