2010-08-08 10 views
8

सभी जावा स्रोत कोड उदाहरणों में मैंने श्रोताओं को हमेशा आंतरिक कक्षाओं में घोषित किया है।जावा - क्या एक्शन लिस्टेनर्स, कीलिस्टेनर्स, आदि, हमेशा आंतरिक कक्षाओं में घोषित किया जाना चाहिए?

क्यों - श्रोताओं को अपने स्वयं के अलग * .java फ़ाइल \ कक्षा में रखने के बजाय इस तरह के वर्गों को कोड करने का कारण क्या है?

श्रोताओं के लिए अलग-अलग कक्षाएं खराब डिजाइन मानी जाएंगी?

यदि यह एक खराब डिज़ाइन \ sackable अपराध नहीं है, तो कृपया कोई छोटा उदाहरण पोस्ट कर सकता है यह दर्शाता है कि इसे कैसे कार्यान्वित किया जाए?

पढ़ने के लिए धन्यवाद।

संपादित करें \ अद्यतन - 10.8.2010: उत्तर देने का समय लेने वाले सभी लोगों के लिए धन्यवाद। विचार करने के लिए अंतर्दृष्टि बिंदुओं के बहुत सारे। सभी उत्तरों को पढ़ने के बाद मुझे लगता है कि जब तक अन्यथा करने का कोई अच्छा कारण न हो, श्रोताओं को आंतरिक कक्षाओं के रूप में घोषित करना बेहतर और आसान होता है।

इस सवाल का जल्दी से वापस आ रहा नहीं करने के लिए क्षमा याचना, लेकिन मैं हमेशा कोडिंग के रूप में मैं :-(चाहते हैं

मुबारक कोडिंग के लिए के रूप में ज्यादा समय नहीं है।

उत्तर

6

के बीच अच्छा कारण:

  • अपने पैकेज नाम स्थान
  • करने के लिए अतिरिक्त उच्च-स्तरीय कक्षाओं जोड़ने से बचते भीतर स्थानीय रूप से समझाया कोड (जैसे रखता है घटक है कि घटना से निपटने के व्यवहार)
  • स्थिर इनर क्लासों अच्छी तरह से काम जब वे संलग्नित क्लास के क्षेत्रों तक पहुँचने के लिए की जरूरत नहीं है की आवश्यकता है

शीर्ष स्तर के वर्गों का उपयोग करने के संभावित कारण:

  • आपके पास एक विशेष प्रकार का श्रोता है जिसे आप बाहरी पैकेज द्वारा उपयोग करने की उम्मीद करते हैं या आपके एपीआई (जैसे उदा।इनर क्लासों आमतौर पर पसंद किया जाता है, लेकिन अगर आपके पास: जावा वर्ग ही पुस्तकालय)
  • श्रोता कई स्थानों में प्रयोग किया जाता है, और तार्किक कई संभावित संलग्न वर्गों

संक्षेप में से किसी एक के लिए विशिष्ट नहीं है में अच्छे कारण तो इसके बजाय शीर्ष स्तर की कक्षाएं बनाने के लिए यह पूरी तरह से समझदार हो सकता है।

0

आप देखा है तो उदाहरणों में उन्हें शायद यह आसान लग रहा है। अधिकांश शायद आपको अपनी वर्तमान कक्षा लेने और श्रोता को लागू करने के लिए बताएंगे। कौन सा आसान दिखता है: 2 वर्गों में 2 कक्षाएं बनाना, मुख्य वर्ग के अंदर नेस्टेड श्रोता का उपयोग करना, या सिर्फ अपनी मुख्य कक्षा श्रोता के रूप में है? (संकेत: यह पहला नहीं है)

मैं आलसी हूं और केवल एक मुख्य वर्ग ए को लागू करता है ctionListener इंटरफ़ेस। यह निश्चित रूप से केवल बहुत ही सरल जीयूआई पर काम करता है। बड़ी परियोजनाओं के लिए आपको उन्हें अलग करना चाहिए।

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

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

0

आप निश्चित रूप से श्रोता को एक अलग वर्ग फ़ाइल में एक अलग .java फ़ाइल में लागू कर सकते हैं। जावा 1.1 ने अज्ञात वर्ग और आंतरिक वर्ग के विचार को साल पहले पुन: डिजाइन के साथ प्रस्तुत किया था। कारण यह है कि कई बार, आपके द्वारा लिखे गए श्रोताओं को कक्षा से फ़ील्ड को अपडेट करने और/या पढ़ने की आवश्यकता होती है जिसमें ऑब्जेक्ट्स उत्पन्न होते हैं। इन क्षेत्रों को गैर-आंतरिक/अज्ञात वर्ग से संदर्भित करना बोझिल है।

एक बार जब आप अज्ञात वर्गों का अधिक उपयोग करते हैं, तो आप देखेंगे कि यह बाद में लिखने और बनाए रखने के लिए चीजों को आसान बनाता है। आधुनिक आईडीई भी आपके लिए सबसे अधिक कोड उत्पन्न करेगा। उदाहरण के लिए, IntelliJ IDEA में इन दो पंक्तियों में कुंजी और ctrl-shift-space दबाएं। IntellJ एक अज्ञात वर्ग डालेगा जो addActionListener() द्वारा निर्दिष्ट इंटरफ़ेस के सभी तरीकों को बाधित करता है।

JButton jb = new JButton("ok"); 
jb.addActionListener(new 
0

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

श्रोताओं के लिए सामान्य उपयोग यह है कि वे केवल एक ही स्थान पर उपयोग किए जाते हैं और उस उद्देश्य के लिए अनाम आंतरिक कक्षाएं परिपूर्ण होती हैं। कई तरीकों से इंटरफ़ेस के लिए (जैसे माउसलिस्टनर) आमतौर पर एक सब कुछ के खाली कार्यान्वयन के साथ एक संबंधित एडाप्टर होता है जिसे आवश्यकतानुसार ओवरराइड किया जा सकता है। MouseAdapter देखें।

1

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

यह देखने का एक और तरीका यह हो सकता है कि श्रोताओं को यूआई में इंजेक्शन दिया जाए। हो सकता है कि वे नियंत्रक द्वारा प्रदान किए जाएं, जो यूआई को तुरंत चालू करता है और यह बताता है कि यूआई घटनाओं पर प्रतिक्रिया कैसे करें।

मुझे लगता है कि यह दुनिया के निर्भरता इंजेक्शन दृश्य से अधिक है। इसके लिए महत्वपूर्ण फायदे हो सकते हैं।

1

This answer विभिन्न तरीकों के व्यापार बंदों पर चर्चा करता है।

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

+0

लिंक के लिए धन्यवाद, टोफूबीर। –

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

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