सी # एनोमिंग कन्वेंशन फॉर एनम एंड मैचिंग प्रॉपर्टी


93

मैं अक्सर अपने आप को एक वर्ग के रूप में कुछ प्रकार की स्थिति की संपत्ति बनाए रखने के लिए खुद को एनम के रूप में कार्यान्वित करता हूं: मेरे पास एक स्टेटस इनम और वन स्टेटस प्रॉपर्टी ऑफ स्टेटस टाइप है। मुझे इस नाम संघर्ष को कैसे हल करना चाहिए?

public class Car
{
  public enum Status
  {
    Off,
    Starting,
    Moving
  };

  Status status = Status.Off;

  public Status Status // <===== Won't compile =====
  {
    get { return status; }
    set { status = value; DoSomething(); }
  }
}

अगर स्टेटस इनम अलग-अलग तरह के होते हैं, तो मैं इसे क्लास के बाहर रख दूंगा और समस्या हल हो जाएगी। लेकिन स्थिति केवल कार पर लागू होती है इसलिए क्लास के बाहर एनम को घोषित करने का कोई मतलब नहीं है।

इस मामले में आप किस नामकरण सम्मेलन का उपयोग करते हैं?

एनबी: इस सवाल का इस सवाल के जवाब की टिप्पणियों में आंशिक रूप से बहस हुई थी । चूंकि यह मुख्य प्रश्न नहीं था, इसलिए इसे बहुत अधिक दृश्यता नहीं मिली।

EDIT: फिलिप एकबर्ग 'स्टेटस' के विशिष्ट मामले के लिए एक उत्कृष्ट IMO का सुझाव देता है। फिर भी मैं उन समाधानों के बारे में पढ़ने के लिए दिलचस्प हूं जहां माइकल प्रेवेकी के जवाब में, एनम / संपत्ति का नाम अलग है ।

EDIT2 (मई 2010): मेरा पसंदीदा समाधान एनम प्रकार के नाम का बहुवचन करना है, जैसा कि क्रिस एस। लेकिन मैं इसे ज्यादा से ज्यादा पसंद करने आया हूं। मैं अब इसे नियमित रूप से enums के लिए भी उपयोग करते हैं।


1
मुझे नहीं लगता कि इसके लिए कई अच्छे समाधान हैं यदि आप अपनी कक्षा के अंदर एनम नेस्टेड होना चाहते हैं। मैं वास्तव में एनम को अलग करना पसंद करता हूं फिर यह एक समस्या पेश नहीं करता है, लेकिन मैं आपकी बात को दार्शनिक रूप से घोंसला बनाने के लिए देख सकता हूं।
क्रेग शीयर

जवाबों:


32

मैं चर्चा में अपना 1 यूरो जोड़ूंगा लेकिन यह शायद कुछ नया नहीं जोड़ रहा है।

स्पष्ट समाधान स्थिति को नेस्टेड एनम होने से बाहर ले जाना है। अधिकांश .NET enums (संभवतः Windows.Forms नामस्थान में कुछ को छोड़कर) नेस्टेड नहीं हैं और यह आपके एपीआई का उपभोग करने वाले डेवलपर के लिए उपयोग करने के लिए कष्टप्रद बनाता है, क्लासनाम को उपसर्ग करता है।

एक बात जिसका उल्लेख नहीं किया गया है वह यह है कि MSDN दिशानिर्देशों के अनुसार ध्वज एनमों का बहुवचन संज्ञा होना चाहिए जिसे आप शायद पहले से ही जानते हैं (स्थिति एक सरल एनम है इसलिए एकवचन संज्ञाओं का उपयोग किया जाना चाहिए)।

राज्य (enum कहा जाता है राज्य) शब्द है, "स्थिति" एक संज्ञा का नाममात्र है जिसे अंग्रेजी हमारी अधिकांश भाषा लैटिन से अवशोषित कर लेती है। Vocative जिसे आप अपनी स्थिति के लिए एक संज्ञा का नाम देते हैं और नामांक क्रिया का विषय है।

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

public class Car
{
  VehicleState _vehicleState= VehicleState.Stationary;

  public VehicleState VehicleState 
  {
    get { return _vehicleState; }
    set { _vehicleState = value; DoSomething(); }
  }
}

public enum VehicleState
{
    Stationary, Idle, Moving
}

राज्य इस तरह के एक सामान्यीकृत संज्ञा है यह वर्णन करना बेहतर नहीं होगा कि यह किस राज्य की बात कर रहा है? जैसे मैंने ऊपर किया

मेरे विचार में भी प्रकार का उदाहरण पाठक प्रकार को संदर्भित नहीं करता है, लेकिन इसका डेटाबेस। मैं इसे पसंद करूंगा यदि आप पाठक के डेटाबेस उत्पाद का वर्णन कर रहे हैं जो आवश्यक रूप से पाठक के प्रकार के लिए प्रासंगिक नहीं है (उदाहरण के लिए पाठक का प्रकार केवल आगे, कैश्ड और इसी तरह हो सकता है)। इसलिए

reader.Database = Databases.Oracle;

वास्तव में ऐसा कभी नहीं होता है क्योंकि वे चालक के रूप में कार्यान्वित किए जाते हैं और एंथम का उपयोग करने के बजाय एक विरासत श्रृंखला होती है यही कारण है कि ऊपर की रेखा प्राकृतिक नहीं लगती है।


24
मेरी समझ यह है कि झंडे को बहुवचन बनाया जाना चाहिए, न कि सरल दुश्मनी को।
सर्ज वेटियर

8
कक्षा से बाहर जाने के बारे में, मुझे अभी तक यह समझ नहीं आया है कि CarState Car.State से अधिक सुविधाजनक क्यों है। हालाँकि, मैं एक कक्षा से बाहर आने के सकारात्मक पक्ष को नहीं समझता हूँ जब यह एनम केवल इस वर्ग के व्यवहार का वर्णन करता है।
सर्ज वेटियर

मुझे फाइल संज्ञा जैसे संज्ञा वाक्यांश लिखने चाहिए, न कि केवल संज्ञाएं, मैंने उत्तर अपडेट कर दिया है। मुझे लगता है कि classname.Enum सिर्फ एक प्राथमिकता है - मुझे उस रूपरेखा में कोई उदाहरण नहीं मिल सकता है जिसे मैं कॉपी करता हूं।
क्रिस एस

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

1
मुझे पता है कि मैं यहां 1 1/2 साल देर से आया हूं, लेकिन उदाहरण में public class EngineStateहोना चाहिए public enum EngineState, है ना?
डेविड मर्डोक

36

"ऑफ", "स्टार्टिंग" और "मूविंग" की परिभाषा वह है जिसे मैं "स्टेट" कहूंगा। और जब आप यह अनुमान लगा रहे हैं कि आप "राज्य" का उपयोग कर रहे हैं, तो यह आपकी "स्थिति" है। इसलिए!

public class Car
{
  public enum State
  {
    Off,
    Starting,
    Moving
  };

  State state = State.Off;

  public State Status
  {
    get { return state ; }
    set { state= value; DoSomething(); }
  }
}

यदि हम उस उदाहरण से एक और उदाहरण लेते हैं जहाँ आप इस मामले में "टाइप" शब्द का उपयोग करना चाहते हैं:

public class DataReader
{
    public enum Type
    {
        Sql,
        Oracle,
        OleDb
    }

    public Type Type { get; set; } // <===== Won't compile =====

}

आपको वास्तव में यह देखने की ज़रूरत है कि एनम और एनम के बीच अंतर है, है ना? लेकिन एक रूपरेखा बनाते समय या वास्तुकला के बारे में बात करने के लिए आपको सिमिलरिटीज़ पर ध्यान देने की आवश्यकता होती है, ठीक है, उन्हें खोजने दें:

जब कोई चीज़ किसी स्थिति पर सेट होती है, तो उसे "चीज़" स्थिति के रूप में परिभाषित किया जाता है

उदाहरण: कार की स्थिति रनिंग स्टेट, स्टॉप्ड स्टेट आदि में है।

आप दूसरे उदाहरण में क्या हासिल करना चाहते हैं यह कुछ हद तक है:

myDataReader.Type = DataReader.Database.OleDb

आप सोच सकते हैं कि यह जो मैं दूसरों के बारे में प्रचार कर रहा हूं, उसके खिलाफ कहता है कि आपको एक मानक का पालन करने की आवश्यकता है। लेकिन, आप एक मानक का पालन कर रहे हैं! Sql-case एक विशिष्ट मामला है और अस्वस्थ है इसलिए इसे कुछ विशिष्ट समाधान की आवश्यकता है।

हालाँकि, आपके System.Dataस्थान के भीतर enum फिर से प्रयोग करने योग्य होगा , और यही पैटर्न है।

"टाइप" को देखने का एक और मामला "एनिमल" है जहां टाइप प्रजाति को परिभाषित करता है।

public class Animal
    {
        public enum Type
        {
            Mammal,
            Reptile,
            JonSkeet
        }

        public Type Species{ get; set; }

    }

यह एक पैटर्न का अनुसरण कर रहा है, आपको इसके लिए ऑब्जेक्ट को "जानने" की विशेष आवश्यकता नहीं है और आप "AnimalType" या "DataReaderType" को निर्दिष्ट नहीं कर रहे हैं, आप अपनी पसंद के नामस्थान में फिर से एनम का उपयोग कर सकते हैं।


1
मेरा मानना ​​है कि "स्थिति" नाम केवल एक उदाहरण था। अन्य स्थितियों के बारे में क्या, जब आप स्थिति / स्थिति पर भरोसा नहीं कर सकते? उदा ए टाइप एनम ...
डैन सी।

क्या आप इसके लिए एक उदाहरण परिदृश्य प्रदान कर सकते हैं? बीमार उस अस्वस्थ के अनुसार मेरे उत्तर का विस्तार करने की कोशिश करते हैं :)
फिलिप एकबर्ग

2
@ फ़ीलिप: एनिमल टाइप सैंपल में बताया गया है कि पहली टिप्पणी में मेरा क्या मतलब था, यानी यह एनम का बहुत "रीवॉर्डिंग" है। एनम और संपत्ति के नाम के लिए समानार्थक शब्द का उपयोग करना कोड को कुछ भ्रमित करता है, मुझे लगता है।
दान सी।

1
मुझे भी लगता है कि 'प्रजाति' केवल इस प्रकार के जानवरों के लिए (इस मामले में जानवरों के लिए) एक रीवॉर्डिंग है।
लेजेंड लैंथ

2
बस नाम बदलना हमेशा साफ नहीं होता है - उदाहरण के लिए एक प्लेइंग कार्ड के लिए एक वर्ग के बारे में सोचें, एक एनम सूट और एक संपत्ति सूट के साथ - बिल्कुल क्या नाम बदलें? अनाड़ी रास्ता।
annakata 10

9

मुझे लगता है कि यहाँ असली समस्या यह है कि एनम स्टेटस आपकी कक्षा के भीतर इनकैप्सुलेटेड है, जैसे कि Car.Statusप्रॉपर्टी Statusऔर एनम दोनों के लिए अस्पष्ट हैStatus

बेहतर अभी तक, कक्षा के बाहर अपनी दुश्मनी डालें:

public enum Status
{
    Off,
    Starting,
    Moving
}

public class Car
{
    public Status Status
    { ... }
}

अपडेट करें

नीचे दी गई टिप्पणियों के कारण, मैं अपने डिज़ाइन को ऊपर बताऊंगा।

मैं वह हूं जो विश्वास नहीं करता कि एनम या वर्ग या कोई अन्य वस्तु किसी अन्य वर्ग के अंदर होनी चाहिए , जब तक कि वह उस कक्षा के भीतर पूरी तरह से निजी न हो। उदाहरण के लिए उपरोक्त उदाहरण लें:

public class Car
{
    public enum Status
    {...}
    ...
    public Status CarStatus { get; set;}
}

हालांकि कुछ टिप्पणीकारों का तर्क होगा कि स्थिति का क्लास कार के दायरे से बाहर कोई मतलब नहीं है, इस तथ्य को कि आप एक सार्वजनिक संपत्ति सेट कर रहे हैं इसका मतलब है कि प्रोग्राम के अन्य हिस्से हैं जो उस एनम का उपयोग करेंगे :

public Car myCar = new Car();
myCar.CarStatus = Car.Status.Off;

और यह मेरे लिए एक कोड गंध है। मुझे लगता है कि स्थिति को देखने के लिए जा रहा हूँ, तो बाहर की Car, मैं भी यह परिभाषित कर सकता है बाहर के रूप में अच्छी तरह से।

जैसे, मैं शायद इसका नाम बदल दूंगा:

public enum CarStatus
{...}

public class Car
{
    ...
    public CarStatus Status { get; set; }
}

हालांकि, अगर उस एनम का उपयोग केवल और केवल कार क्लास के भीतर ही किया जाएगा , तो मैं वहां एनम की घोषणा करने के साथ ठीक हूं।


यह स्थिति वैश्विक बना देगा, आप इसे केवल एक विशिष्ट क्षेत्र के अंदर रखना चाह सकते हैं। अन्य प्रकार जैसे "मानव" के लिए "स्थिति" में "प्रारंभ" नहीं हो सकता है। लेकिन आपको एक पैटर्न का पालन करना चाहिए।
फिलिप एकबर्ग

नहीं, वह हाजिर नहीं है। एनम 99% मामलों में वही शब्द है जो आप संपत्ति के लिए उपयोग करना चाहते हैं। एक एनुम सिर्फ एक नामांकित ध्वज है, इसलिए यह बाहर रहने में बहुत कम नुकसान करता है (वर्गों के विपरीत जिसमें तर्क होते हैं)
क्विबल्सम

जॉन, यह ठीक मेरी बात है: स्टेटस इनम केवल कार के बारे में अर्थपूर्ण है। पूरी तरह से विभिन्न प्रकार की वस्तुओं में पूरी तरह से अलग स्थिति होगी
सर्ज वुटियर

हालांकि वे अलग-अलग नामस्थानों में होंगे, इसलिए यह मायने नहीं रखेगा
क्रिस एस

कार के बाहर इसे देखने के लिए समझाना समझ में आता है। लेकिन मेरे मामले में मेरे दो वर्ग हैं, ORऔर CR। दोनों के पास राज्यों का अपना सेट है, इसलिए यह उन्हें अपने स्वयं के दायरे से बाहर परिभाषित करने का विकल्प नहीं है।
deed02392

4

मुझे पता है कि मेरा सुझाव .NET नामकरण सम्मेलनों के खिलाफ जाता है, लेकिन मैं व्यक्तिगत रूप से 'E ’के साथ उपसर्ग करता हूं और to F’ के साथ Enum फ्लैग करता हूं (इसी तरह हम' I 'के साथ इंटरफैस कैसे करते हैं)। मुझे वास्तव में समझ में नहीं आता है कि यह सम्मेलन क्यों नहीं है। Enums / Flags Interfaces की तरह एक विशेष मामला है जो कभी भी अपने प्रकार को नहीं बदलेगा। न केवल यह स्पष्ट करता है कि यह क्या है, यह इंटेलीजेंस में टाइप करना बहुत आसान है क्योंकि उपसर्ग अधिकांश अन्य प्रकार / चर / आदि को फ़िल्टर करेगा, और आपके पास ये नामकरण क्लैश नहीं होंगे।

और इससे एक और समस्या का भी समाधान होगा जहाँ WPF में उदाहरण के लिए वे enums (जैसे FontWeights) जैसे स्थैतिक वर्गों का उपयोग करते हैं जिनके पास पूर्व-निर्धारित प्रकार के उदाहरण हैं, लेकिन आपको नहीं पता होगा कि क्या आप इसके लिए खोज नहीं करते हैं। यदि वे सिर्फ 'ई' के साथ उन्हें उपसर्ग करते हैं, तो आपको इन विशेष स्थिर वर्गों को खोजने के लिए चरित्र पर लिखना होगा।


4

हंगेरियन नोटेशन और इसके वैरिएंट्स से नफरत की जा सकती है। मैं के साथ प्रत्यय शत्रुओं के एक सम्मेलन का उपयोग करता हूं - इसके लिए प्रतीक्षा करें - Enum। फलस्वरूप मुझे आपके द्वारा बताई गई समस्या कभी नहीं आती है, उन्हें कॉल करने के लिए समय बर्बाद करने की चिंता होती है और कोड बूट करने के लिए पठनीय और स्व-वर्णनात्मक होता है।

public class Car
{
  public enum StatusEnum
  {
    Off,
    Starting,
    Moving
  };

  public StatusEnum Status { get; set; }

}

9
हालांकि उस के लिए माइक्रोसॉफ्ट के सम्मेलनों कृपया ध्यान रखें Enumerations नामकरण : कहते हैं एक्स ऐसा नहीं enum प्रकार के नाम में एक "enum" प्रत्यय का उपयोग करें।
डेविड

2
क्योंकि माइक्रोसॉफ्ट के सम्मेलन समय की कसौटी पर खरे उतरे हैं।
nathanchere

2

मैं संपत्ति का नाम "करंटस्टैटस" की तरह बदल दूंगा। त्वरित एक आसान :)


1

मेरा सुझाव है कि "विकल्प" को टाइप नाम (या ध्वज में यदि इसमें थोड़ा झंडे होते हैं) जोड़ा जाता है, तो इसका प्रकार Car.StatusOption है और संपत्ति Car.Status है।

बहुवचन की तुलना में, यह एनम प्रकार के संग्रह बनाते समय नामकरण टकराव से बचा जाता है, जहां आप सामान्य रूप से संग्रह संपत्ति का बहुवचन करना चाहेंगे , न कि एनम प्रकार का


0

मैं आमतौर पर एनमों को उपसर्ग करता हूं, जैसे कारस्टैटस। मुझे लगता है कि यह सब उस टीम पर निर्भर करता है, जिसके साथ आप काम कर रहे हैं (यदि उनके पास उस प्रकार की कोई नियम / प्रक्रिया है) और ऑब्जेक्ट उपयोग करते हैं। बस मेरे 2 सेंट (:


1
यह वास्तव में MyObjectName स्थिति के विपरीत होने वाले नामकरण सम्मेलन को मार देगा।
फ़िलिप एकबर्ग

कक्षा से
नामकरण
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.