2010-08-26 20 views
8

मैं पूछना चाहता हूं कि अज्ञात वर्ग बनाम आंतरिक कक्षाओं का उपयोग करने पर अच्छा अभ्यास क्या है?जावा/एंड्रॉइड: अज्ञात स्थानीय वर्ग बनाम नाम वर्ग

मैं एक एंड्रॉइड एप्लिकेशन लिख रहा हूं, जिसमें कई यूआई तत्व (बटन, टेक्स्ट फ़ील्ड इत्यादि) शामिल हैं। उनमें से कई के लिए मैं श्रोताओं के कुछ प्रकार की जरूरत है, इसलिए आवेदन के onCreate में मैं की तरह काफी छोटा गुमनाम वर्गों के समूह है:

someButton.setOnClickListener(
    new View.OnClickListener() { 
     public void onClick(View v) { 
      // do something... 
     } 
    } 
); 

ऐसे गुमनाम वर्ग के से प्रत्येक 5 - 20 लाइनों बड़ा - छोटे पर्याप्त और संक्षेप पुस्तक में जावा ™ से सिफारिशों के लिए अच्छा फिट बैठता है:

सामान्य तौर पर, आप एक स्थानीय वर्ग के बजाय एक अनाम वर्ग के उपयोग पर विचार करना होगा जबकि:

  • कक्षा में बहुत छोटा शरीर है।
  • कक्षा के केवल एक उदाहरण की आवश्यकता है।
  • कक्षा परिभाषित होने के ठीक बाद उपयोग की जाती है।
  • कक्षा का नाम आपके कोड को समझने में आसान नहीं बनाता है।

लेकिन समस्या यह है, IMO, कि onCreate काफी बड़ा हो जाता है और कोड अधिक पढ़ सकते हैं और जल्दी यह करने में देख कर समझने के लिए जटिल हो जाता है। यह अभी भी समझना आसान है, लेकिन बस बहुत बड़ा है।

तो क्या इस तरह के मामले में बेहतर अभ्यास हो सकता है - छोटे आंतरिक उप-वर्गों, जहां यह के प्रत्येक अच्छी तरह से अलग किया जाता है, लेकिन सिर्फ एक बार या बेहतर इस्तेमाल किया बजाय गुमनाम वर्गों का उपयोग रखने का गुच्छा है?

+0

मेरे अनुभव: गुमनाम वर्ग का उपयोग जारी रखने रखते हैं लेकिन, एक (या अधिक) निजी विधि (रों) करने के लिए अपने कोड का कुछ हिस्सा ले जाएँ और यह (उन्हें) onCreate विधि से कॉल करने के लिए प्रयास करें। – mhshams

उत्तर

8

मुझे नहीं लगता कि वहाँ एक स्पष्ट उत्तर एक ही रास्ता या अन्य है। दोनों शैलियों ठीक काम करते हैं, यह वास्तव में सिर्फ वही है जो आप पसंद करते हैं।

एक अन्य विकल्प के लिए एक एकल समारोह कॉल है, जो गुमनाम वर्गों बहुत ही कम रखेंगे द्वारा

प्रत्येक onClick की सामग्री है। मैं।ई:

someButton.setOnClickListener(
    new View.OnClickListener() { 
     public void onClick(View v) { 
      doSomeButtonClick(); 
     } 
    } 
); 


private void doSomeButtonClick() { 
    // do something 
} 
0

जैसा उद्धरण बताता है, यह कुछ ऐसा है जो व्यक्तिपरक है। आप यह पता लगाने की "बहुत ही कम" और खुद के लिए, किस बिंदु कोड आकार कि कुछ है कि समझ में आता है अपने आप होने के लिए करने के लिए एक अनाम वर्ग के रूप में समझ में आता है कुछ से रेखा को पार पर निर्धारित करने के लिए "को समझना आसान" के रूप में क्या मायने रखता है की जरूरत है इकाई।

कोई जवाब किसी पर यह है कि क्या "लघु" के अपने स्वयं के व्यक्तिपरक उपायों पर आधारित है आप देते हैं और कितने कोड की लाइनें यह अब "लघु" होने के लिए ले जाता है जाएगा।

5

onCreate() को सामान्य कार्यक्षमता द्वारा समूहीकृत विभिन्न विधियों में रिफैक्टर करें ताकि आपके पास तार्किक इकाइयां हों। यदि जीयूआई जटिल है तो यह बाद में आपकी मदद करेगा।

संपादित करें:

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

1

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

लेकिन समय के सबसे अधिक है, अगर वर्ग इस तरह का बड़ा हो जाता है, यह क्योंकि आपके पास पर्याप्त प्रतिनिधि नहीं किया है। हो सकता है कि अन्य वर्गों में विधियां होनी चाहिए जो आपके श्रोता को हल्का होने में मदद करें।

3

मैं डेस्कटॉप/घुमाओ अनुप्रयोगों करते हैं, लेकिन मुझे लगता है कि अवधारणाओं एक ही हैं।

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

यह मैं देता कई फायदे:

  • ईवेंट प्रबंधन कोड के सभी एक कक्षा में है।
  • घटनाओं के बीच कार्यक्षमता में कोई भी क्रॉसओवर आसानी से पकड़ा और संभाला जाता है।
  • किसी भी राज्य को प्रभावित किया जा सकता है जिसे एक वर्ग में संग्रहीत और नियंत्रित किया जा सकता है।
  • सभी ईवेंट हैंडलिंग कोड घटक लेआउट कोड से अलग है।
  • दृश्य परत (पैनल) नियंत्रक परत के बारे में कुछ भी नहीं जानता है।

कहा जा रहा है कि यदि आप जिन घटनाओं को जोड़ रहे हैं, वे सभी सरल चीजें करते हैं, और ये चीजें अन्य घटनाओं के साथ संघर्ष नहीं करती हैं, तो अनाम कक्षाओं का उपयोग करना गलत नहीं है।

+0

यह एक महान तकनीक है जिसका आप उपयोग कर रहे हैं। मुझे लगता है, यह बहुत उपयोगी है जब आपके पास UI घटकों के बीच कई इंटरैक्शन हैं। हालांकि माया सुझाव शायद मेरी जरूरतों के लिए और अधिक फिट बैठता है, लेकिन फिर भी - वास्तव में अच्छा विचार है। मैं इसे भविष्य के लिए अपने दिमाग में रखूंगा, धन्यवाद! – Laimoncijus

0

आप नामित वर्गों में इन मदों डाल करने के लिए कई फायदे हैं।

पहले एक आप का उल्लेख है - यह OnCreate() विधि अधिक संक्षिप्त और समझने कर देगा।

दूसरा यह है कि नाम जल्दी की पहचान करनी चाहिए जो तर्क जो बटन के साथ चला जाता है, जो कर देगा कोड को मंजूरी दे दी

तीसरे कर्तव्यों के आसान जुदाई है। यदि आपको आईओसी मॉडल में जाने का फैसला करना चाहिए, तो आपको श्रोताओं के नामित कार्यान्वयन को इंजेक्शन देने में बहुत आसान समय होगा।

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