2009-12-01 10 views
31

मुझे नियमित तरीकों के स्थान पर हर जगह क्लोजर का उपयोग करने की आदत मिल गई है, भले ही मुझे मुफ्त चर तक पहुंच की आवश्यकता न हो।ग्रोवी: बंद या विधियां

def addNumbers = { left, right -> left + right }

.. बजाय इस की:

def addNumbers (left,right) { left + right }

यह बुरा व्यवहार है तो, मैं इस का प्रयोग करेंगे? तरीकों से बंद होने का उपयोग करते समय मुझे जितनी अतिरिक्त शक्ति मिलती है, मैं अब तक वाक्यविन्यास पसंद करता हूं।

धन्यवाद!

+3

बस याद रखें, कि आप आसानी से रिटर्न प्रकार को बंद नहीं कर सकते हैं। तरीकों के लिए यह बहुत आसान है। साथ ही, क्लोजर '@ टाइप चेकेड' या '@ कंपाइलस्टैटिक' के साथ अच्छी तरह से नहीं खेलते हैं। – Seagull

उत्तर

40

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

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

    1. बंद ही
    2. बंद मालिक
    3. बंद प्रतिनिधि

लेकिन इस क्रम कार्यावधि में बदला जा सकता है, और एक बंद की: डिफ़ॉल्ट विधि को बंद करने के भीतर कॉल करके द्वारा हल कर रहे हैं प्रतिनिधि को किसी ऑब्जेक्ट में भी बदला जा सकता है।

संयुक्त कुछ कोड बंदी बहुत grok की मुश्किल का उपयोग करता है बना सकते हैं इन कारकों में से सभी है, तो आप एक विधि के बजाय

  • एक का उपयोग करके इस जटिलता के किसी भी मैं इसे खत्म करने के लिए पसंद करते हैं की जरूरत नहीं है, तो Groovy में परिभाषित प्रत्येक बंद करने के लिए .class फ़ाइल उत्पन्न होती है। मेरे पास दावा का समर्थन करने के लिए बिल्कुल शून्य सबूत हैं कि एक नियमित विधि बंद होने से अधिक प्रदर्शनकारी है, लेकिन मुझे संदेह है। कम से कम, बहुत से वर्ग आपको पर्मजेन मेमोरी स्पेस से बाहर निकलने का कारण बन सकते हैं - यह तब तक मेरे साथ होता था जब तक कि मैंने अपनी पर्मजेन स्पेस को लगभग 200 एमबी

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

6

जबकि @Don कहता है कि सभी चीजें सच हैं, मुझे नहीं पता कि उनमें से कोई भी महत्वपूर्ण है। आप एक बंद करने वाले प्रतिनिधि को ओवरराइड कर सकते हैं जो निष्पादन को बदल सकता है, लेकिन जब तक कि आप आस-पास बंद नहीं कर रहे हैं (जिसे आप किसी विधि से नहीं कर सकते हैं) आपको वास्तव में उन सभी चीजों के बारे में चिंता करने की ज़रूरत नहीं है। प्रतिनिधि के साथ खेलना एक विशेषता है, न कि देयता।

अतिरिक्त कक्षा फ़ाइलों से संभावित प्रदर्शन के लिए, आप ग्रोवी का उपयोग क्यों कर रहे हैं यदि आप प्रदर्शन के बारे में चिंतित हैं?

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

टीएल; डॉ - कोई कठोर और तेज़ नियम नहीं है, इसके बजाय आपको कोड पठनीयता की ओर नजर रखने के साथ अच्छे निर्णय लेना चाहिए।

+1

मैं पूरी तरह से सहमत हूं कि मेरे अंक अपेक्षाकृत मामूली हैं, और संक्षिप्तता एक और अधिक महत्वपूर्ण विचार है। –

+1

उपयोग के आधार पर, संभवतः अप्रकाशित 'java.lang.ref.SoftReference' उदाहरणों के कारण, बंद होने के अत्यधिक उपयोग से प्रमुख प्रदर्शन और स्मृति गिरावट हो सकती है। नियमित स्क्रिप्ट और कक्षाओं में जो कोई समस्या नहीं होगी, लेकिन कुछ विशेष मामलों में (जैसे 'मार्कअपबिल्डर' से निपटने के लिए विशाल एक्सएमएल) आपको बंद करने का उपयोग करना चाहिए। –

+1

मैं आम तौर पर समयपूर्व अनुकूलन पर अच्छी शैली पसंद करता हूं। समय-समय पर अपने कोड को प्रोफाइल करना हमेशा अच्छा विचार है, और यह आपको अनुकूलित करने के अवसरों की पहचान करने में मदद करेगा। बेशक, ग्रोवी (और इसी तरह जेडीके) की प्रत्येक नई रिलीज ऑप्टिमाइज़ेशन का एक नया सेट ला सकती है, इसलिए आपके कोड को अनुकूलित करना लागत/लाभ के आधार पर किया जाना चाहिए। निचली पंक्ति: सबसे अधिक पठनीय, सहज ज्ञान कोड लिखें जो आप कर सकते हैं और कुछ अनुकूलित करने में समय बर्बाद न करें जो शायद आपके लिए अनुकूलित किया जाएगा। – ngreen