एक enum

Question

के अंदर तर्क मेरे सहयोगियों और मैं enums में तर्क के बारे में एक चर्चा कर रहे थे। मेरी निजी वरीयता में जावा एनम्स में कोई भी तर्क नहीं है (हालांकि जावा ऐसा करने की क्षमता प्रदान करता है)।

public enum PackageType { 
    Letter("01", "Letter"), 
    .. 
    .. 
    Tube("02", "Packaging Tube"); 

    private String packageCode; 
    private String packageDescription; 

    .. 
    .. 

    public static Map<String, String> toMap() { 
    Map<String, String> map = new LinkedHashMap<String, String>(); 
    for(PackageType packageType : PackageType.values()) { 
     map.put(packageType.getPackageCode(), packageType.getPackageDescription()); 
    } 
    return map; 
    } 
} 

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

मेरा तर्क चिंता के अलगाव के आसपास केंद्रित है और किसी सेवा के किसी भी प्रकार के तर्क को सारणीबद्ध करता है। मुझे नहीं लगता था कि "सुविधा" इस विधि को एक enum के अंदर रखने के लिए एक मजबूत तर्क था।

सर्वोत्तम अभ्यास प्रथाओं से, कौन सा बेहतर है? या यह व्यक्तिगत वरीयता और कोड शैली के मामले में बस आ जाता है?

Answer 1

ठीक है, मैंने पहले यह किया है लेकिन निश्चित रूप से इसका मतलब यह नहीं है कि यह करने के लिए 'सबसे अच्छी बात' है।

मेरे परिप्रेक्ष्य से, हालांकि, मैं enum पर उस तर्क को पसंद करना चाहूंगा, इसी कारण से आप किसी सेवा के लिए 'toString' विधि नहीं ले जाएंगे। तर्क केवल enum खुद, और इसके अपने प्रतिनिधित्व से संबंधित है।

मुझे लगता है कि इस तरह की एक विधि को एक सेवा में स्थानांतरित करने के लिए भ्रामक होगा - इसे इस तथ्य के सामने आगे बढ़कर आप इस तथ्य के सामने आगे बढ़ रहे हैं कि enum में 'toMap' विधि है। कोई भी जो सेवा के बारे में नहीं जानता था और सिर्फ enum को देख रहा था उसे पता नहीं हो सकता है।

यह आईडीई के ऑटो पूर्ण होने में भी मदद करता है - मैं '।' कुंजी और तुरंत वस्तु द्वारा प्रदान की गई विधियों को देखें।

Answer 2

मुझे कोई भी प्रेरक कारण नहीं दिख रहा है कि यह "अच्छा अभ्यास" क्यों है या "बुरा अभ्यास" ... जो आप सुझा रहे हैं उसे करने के लिए।

मैं सुविधा तर्क के लिए जाने के इच्छुक हूं। लेकिन स्पष्ट रूप से, यह ऐसी बात नहीं है कि यह पर बहस करने के लिए उत्पादक है ... आईएमओ।

Answer 3

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

enum तर्क के लिए सबसे अच्छा उपयोग केस (क्योंकि यह बहुत स्थिर है) उन चीज़ों के लिए है जो बदलने वाले नहीं हैं। java.util.concurrent.TimeUnit में तर्क इस का एक बहुत अच्छा उदाहरण है: समय इकाइयों के बीच रूपांतरण कारक अच्छी तरह से परिभाषित हैं और कभी भी नहीं बदलेंगे, इसलिए यह enum के भीतर एम्बेडेड स्थिर तर्क के लिए एक अच्छा उम्मीदवार है।

Answer 4

मैं कई बार enums में तर्क की कोशिश की है, लेकिन केवल एक चीज मैं कभी के बारे में वास्तव में खुश हूँ की तरह कुछ है:

// not compiled, so might have errors... 
public enum Foo 
{ 
    A, 
    B; 

    // not complete, doesn't properly handle invalid cases... 
    public static Foo fromString(final String str) 
    { 
     final String strLower; 
     final Foo val; 

     strLower = str.toLowerCase(); 

     if(strLower.equals("a") 
     { 
      val = A; 
     } 
     else if(strLower.equals("b") 
     { 
      val = B; 
     } 
     else 
     { 
      throw new IllegalArgumentException(/*...*/); 
     } 

     return (val); 
    } 
} 

आम तौर पर एक बार आप उदाहरण चर/तरीकों आप शायद कुछ कर रही किया जाना चाहिए जोड़ना शुरू एक उचित वर्ग के साथ।

Answer 5

मैं इसे enum में डालने से शुरू करूंगा। यदि सिस्टम में केवल एक toMap() विधि होगी, तो एक अतिरिक्त कक्षा निश्चित रूप से अनावश्यक है और परेशान होगी।

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

मेरा व्यक्तिगत राय है, व्यावहारिकता सिद्धांत प्रभाव साफ़ हो।

संपादित करें: ओह रुको, इसके लिए एक सामान्य उपयोगिता विधि प्रदान करना मुश्किल होगा .. उस स्थिति में, यदि विधि विशिष्ट है, तो मैं निश्चित रूप से इसे enum में डालकर जाऊंगा। अगर मैं रखरखाव प्रोग्रामर था, तो मैं बहुत असंतुष्ट होगा यदि आपके पास एक अतिरिक्त कक्षा होगी जिसे मुझे देखना है।

Answer 6

कुछ भी यह उपयोग पर निर्भर करेगा की तरह, सामान्य नियम देखते हैं लेकिन व्यावहारिकता हमेशा तर्क जीतने चाहिए। मानचित्र के लिए क्या उपयोग किया जाता है? क्या आपको कभी भी मानचित्र की सामग्री को प्रतिबंधित करने की आवश्यकता होगी, उदा। अगर नक्शा एक कॉम्बो बॉक्स को भरने के लिए प्रयोग किया जाता है, वहाँ कभी कुछ विकल्प को दूर करने की जरूरत है, अगर कुछ वाहकों के केवल कुछ पैकेज प्रकार एक रणनीति मानचित्र को भरने के लिए इस्तेमाल किया जा सकता संभाला, कि सबसे अच्छा enum के बाहर किया जा जाएगा कहते हैं।

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