जावा हमें फ़ाइल नाम से भिन्न नाम वाले वर्ग को संकलित करने की अनुमति क्यों देता है?


170

मेरे पास एक फ़ाइल Test.javaऔर उसके अंदर निम्न कोड है।

public class Abcd
{
        //some code here

}

अब कक्षा संकलन नहीं करती है, लेकिन जब मैं publicसंशोधक को हटाता हूं , तो यह ठीक संकलन करता है।

जावा के पीछे तर्क क्या है जो हमें एक वर्ग नाम संकलित करने की अनुमति देता है जो फ़ाइल नाम से अलग है जब यह सार्वजनिक नहीं है।

मुझे पता है कि यह एक नौसिखिया सवाल है, लेकिन मैं एक अच्छी व्याख्या नहीं पा रहा हूँ।


28
क्योंकि जावा। (क्योंकि यह सार्वजनिक नहीं है, और एक ही नामकरण सम्मेलन का पालन नहीं करना है। इसके अलावा, आपको लोगों से यह पूछने की आवश्यकता होगी कि इसका आविष्कार कैसे हुआ।)
डेव न्यूटन

2
मुझे संदेह है कि एक "अच्छी व्याख्या" है। यह सार्वजनिक वर्गों के लिए एक आवश्यकता थी, लेकिन इसे गैर-सार्वजनिक वर्गों के लिए अनावश्यक माना जाता था।
कयामन

2
इसी तरह का प्रश्न लगता है: stackoverflow.com/questions/7633631/…
sanket

4
इस प्रश्न के लिए इतने सारे उथल-पुथल क्यों हैं, सबसे पहले इसके दोहरे प्रश्न: stackoverflow.com/questions/7633631/…
GM रमेश

2
@ रमेश: इस सवाल का शीर्षक और विषय
वस्तु

जवाबों:


325

औचित्य प्रति .javaफ़ाइल एक से अधिक शीर्ष-स्तरीय वर्ग की अनुमति है ।

कई वर्ग - जैसे कि घटना श्रोता - केवल स्थानीय उपयोग के हैं और जावा के शुरुआती संस्करणों नेस्टेड वर्गों का समर्थन नहीं किया है। "फ़ाइल नाम = वर्ग नाम" नियम की इस छूट के बिना, प्रत्येक और प्रत्येक वर्ग को अपनी फ़ाइल की आवश्यकता होगी, जिसमें छोटी .javaफ़ाइलों के अंतहीन प्रसार का अपरिहार्य परिणाम और कसकर युग्मित कोड का बिखरना होगा।

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


60
+1, यह वास्तव में एक कारण प्रदान करता है , जो प्रश्न है।
डेव न्यूटन

4
विशेष रूप से ऐतिहासिक जानकारी के लिए +1 - मुझे संदेह है कि नेस्टेड / अनाम कक्षाओं के आगमन के साथ, यदि एक ही निर्णय अब किया जाना था (पीछे की संगतता के बारे में परवाह नहीं) तो यह सिर्फ एक शीर्ष स्तर वर्ग के प्रति अनुमति देने के लिए बहुत अधिक समझ में आएगा। फ़ाइल।
माइकल बेरी

1
@ berry120 शायद, क्योंकि यह भत्ता संकलन करते समय फ़ाइल खोज को जटिल करता है।
मार्को टोपोल्निक

3
@Val यह नकारते हुए कि अन्य लोग टेक्स्ट एडिटर और CLI टूल्स का उपयोग करने के लिए विकसित करेंगे क्योंकि आपके द्वारा पसंद की जाने वाली IDE मौजूद है, जैसा कि यह कहना है कि IDE बनाने का कोई मतलब नहीं है क्योंकि आप उनके बिना विकास कर सकते हैं। गुणवत्ता कोड बनाने के लिए अच्छे डेवलपर्स द्वारा दोनों दृष्टिकोणों का उपयोग किया जाता है; और केवल एक ही बात है कि सभी डेवलपर्स में से किसी एक को निपटाने और कुंबया को गाने की बाधाओं से छोटी है, हम सभी को इस बात पर सहमत होंगे कि सबसे अच्छी प्रोग्रामिंग भाषा क्या है।
डैन इज़ फिडलिंग बाय फायरलाइट

5
Emacs (या विम, अपना ज़हर चुनें) और यूनिक्स शैल उपयोगिताओं का संयोजन शायद आधुनिक IDE के रूप में सब कुछ-पर-आपकी उंगलियों के रूप में नहीं है, और वे निश्चित रूप से सीखने के लिए कठिन हैं, लेकिन उनके पास दो जबरदस्त फायदे हैं हर आईडीई जो मैंने कभी कोशिश की है: वे कभी भी दुर्घटनाग्रस्त नहीं होते हैं, कोई फर्क नहीं पड़ता कि कोडबेस कितना विशाल है, और वे मेरी टाइपिंग के साथ रख सकते हैं।
zwol

80

इसका कारण डोर प्लेट्स के लिए समान है। यदि कोई व्यक्ति आधिकारिक रूप से कार्यालय में रहता है (सार्वजनिक घोषित किया जाता है) तो उसका नाम दरवाजे के टैग पर होना चाहिए। जैसे "एलेक्स जोन्स" या "डिटेक्टिव कोलंबो"। यदि कोई व्यक्ति केवल कमरे में जाता है, किसी अधिकारी से बात करता है या फर्श को साफ करता है, तो उनके नाम को आधिकारिक तौर पर दरवाजे पर लगाने की आवश्यकता नहीं है। इसके बजाय, दरवाजा "उपयोगिताएँ" या "मीटिंग रूम" पढ़ सकता है।

आधिकारिक नाम या MyClass.java बैठक कक्ष या टेस्ट.जावा


4
निश्चित रूप से एक दिलचस्प सादृश्य; यह थोड़ा सा स्पष्टीकरण के साथ भी बेहतर हो सकता है कि यह सीधे कैसे संबंधित है। ओपी को संबंध बनाने में कुछ कठिनाई हो सकती है (हालांकि मैं इसे पूरी तरह से समझता हूं)
एंड्रयू बार्बर 16

4
@AndrewBarber मुझे नहीं लगता कि सादृश्य वास्तव में फिट बैठता है क्योंकि यह एक सार्वजनिक वर्ग को मॉडल नहीं करता है, फ़ाइल को कई पैकेज-निजी कक्षाओं के साथ साझा करता है। यह "हीथर सैंटी, प्रबंधक" पढ़ने की डोर प्लेट की तरह है, लेकिन कमरा वास्तव में हीथर और उसके दो सचिवों का है।
मार्को टोपोलनिक 21

@MarkoTopolnik मुझे इसमें शामिल नहीं होना चाहिए था; मैं क्लासिस -ए पर भयानक हूँ ! ;)
एंड्रयू नाई

@AndrewBarber मैं इसे वैसे भी लिखना चाहता था; आपने बस एक धक्का दिया :) सादृश्य भी सबसे तीव्र चिंता व्यक्त करने में विफल रहता है: बस इस विशेषता के कारण कंपाइलर को सभी वर्गों को खोजने के लिए सभी फाइलों को पार्स करना चाहिए, अन्यथा यह केवल निर्देशिका लिस्टिंग को पढ़ सकता है और सभी के नाम जान सकता है शीर्ष स्तर की कक्षाएं।
मार्को टोपोलनिक

@AndrewBarber, सादृश्य पूरी तरह से निर्देशिका के विचार को फिट करता है, लंबे गलियारे में आप जल्दी से एक व्यक्ति को केवल प्लेट प्लेटों पर नज़र लगाकर पा सकते हैं, आपको प्रत्येक कमरे में प्रवेश करने और पूछने की आवश्यकता नहीं है।
एक्सबुक

29

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


20
लेकिन "जावा ने हमें इसकी अनुमति देने के पीछे क्या तर्क दिया है?"
मार्को टोपोलनिक

@MarkoTopolnik क्योंकि यह हमें रोकता नहीं है: D
Maroun

8
@MarounMaroun लेकिन हमें न रोकने के पीछे क्या तर्क है?
मार्को टोपोलनिक

@Marko Java में एक ही फ़ाइल में कई वर्गों को परिभाषित करने की अनुमति है (जब तक कि उनमें से केवल एक ही सार्वजनिक है)। जैसा कि एक ही पैकेज के भीतर सभी वर्गों के पास एक अलग नाम होना चाहिए, गैर-सार्वजनिक कक्षाओं को फ़ाइल नाम के अलावा किसी अन्य नाम की अनुमति देने के अलावा कोई अन्य विकल्प नहीं है।
नॉट 2बैड

2
मेरे 2 सेंट: शायद इसे क्लासपाथ के अंदर कक्षाओं के त्वरित स्थानीयकरण के लिए डिज़ाइन किया गया था। इस सम्मेलन के साथ, कक्षा की खोज के लिए फ़ाइल नामों / रास्तों का निरीक्षण करना पर्याप्त है। इस सम्मेलन के बिना, क्लासपैथ क्लास लोडर को कक्षाएं खोजने के लिए फाइलों को खोलने और पार्स करने की आवश्यकता हो सकती है
आंद्रेई निकुसन

13

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

ओरेकल की वेबसाइट पर नेस्टेड क्लासेस जावा ट्यूटोरियल में सभी नेस्टेड कक्षाओं की एक अच्छी व्याख्या है , जिसमें प्रत्येक के उदाहरण हैं। इसका एक कारण यह भी है कि वे उपयोगी हैं, जो मैं उद्धृत करूंगा:

नेस्टेड क्लास का उपयोग क्यों करें?

नेस्टेड वर्गों का उपयोग करने के लिए सम्मोहक कारणों में निम्नलिखित शामिल हैं:

  • यह तार्किक रूप से समूहन वर्गों का एक तरीका है जो केवल एक ही स्थान पर उपयोग किया जाता है : यदि कोई वर्ग केवल एक अन्य वर्ग के लिए उपयोगी है, तो उसे उस कक्षा में एम्बेड करना और दोनों को एक साथ रखना तर्कसंगत है। ऐसे "हेल्पर वर्गों" को घोंसले बनाने से उनके पैकेज को अधिक सुव्यवस्थित किया जाता है।

  • यह एन्कैप्सुलेशन को बढ़ाता है : दो शीर्ष-स्तरीय कक्षाएं, ए और बी पर विचार करें, जहां बी को ए के सदस्यों तक पहुंच की आवश्यकता है जो अन्यथा निजी घोषित किए जाएंगे। कक्षा बी को कक्षा ए के भीतर छिपाकर, ए के सदस्यों को निजी घोषित किया जा सकता है और बी उन्हें एक्सेस कर सकते हैं। इसके अलावा, बी खुद को बाहरी दुनिया से छिपाया जा सकता है।

  • यह अधिक पठनीय और बनाए रखने योग्य कोड को जन्म दे सकता है : शीर्ष-स्तरीय कक्षाओं के भीतर छोटी कक्षाओं को घोंसले में रखना कोड को उस स्थान के करीब रखता है जहां इसका उपयोग किया जाता है।

(जोर मेरा)

मैं शुरुआती दिनों में जावा स्पेक से परिचित नहीं हूं, लेकिन जावा 1.1 में एक त्वरित खोज शो इनर क्लासेस को जोड़ा गया था।


उन मामलों में क्या करना चाहिए जहां एक प्रकार केवल दूसरे प्रकार के भीतर उपयोगी है, लेकिन पूर्व प्रकार के उदाहरण बाद के उदाहरणों से जुड़े नहीं हैं?
सुपरकैट

नेस्टेड कक्षाएं लैम्ब्डा या 'फर्स्ट क्लास फंक्शंस जब सब कुछ एक वस्तु है' करने का जावा 1.2 तरीका है। यह 1.8 सिंटेक्स में बदल रहा है। जब हम जावा के टाइप सिस्टम में बीजगणितीय डेटा प्रकारों को मॉडल करना चाहते हैं तो उनका उपयोग किया जाता है।
हौवेकी

12

मैं इसे दूसरे तरीके से देखता हूं। प्रोग्रामर के लिए स्वतंत्र रूप से क्लास नाम और फ़ाइल नाम दोनों को चुनने के लिए मामलों की प्राकृतिक स्थिति होगी। संभवतः संकलन के दौरान एक पैकेज के बाहर से सार्वजनिक कक्षाओं को ढूंढने को आसान बनाने के लिए, एक विशेष प्रतिबंध है कि एक सार्वजनिक वर्ग संबंधित नाम वाली फ़ाइल में हो।


4

ध्यान दें कि जावा केस-संवेदी है, लेकिन फाइलसिस्टम की आवश्यकता नहीं है। यदि फ़ाइल का आधार नाम "abcd" है, लेकिन वर्ग "Abcd" है, तो क्या यह केस-असंवेदनशील फाइल सिस्टम पर नियम के अनुरूप होगा? निश्चित रूप से ऐसा नहीं है जब किसी केस-संवेदी को पोर्ट किया गया हो।

या मान लीजिये कि आपके पास ABCD नामक एक वर्ग है, और एक वर्ग Abcd (चलिए इसमें बुरा विचार नहीं है: यह हो सकता है) और कार्यक्रम को असंवेदनशील फाइल सिस्टम में पोर्ट किया गया है। अब आपको न केवल फ़ाइलों का नाम बदलना होगा, बल्कि कक्षाएं, उफ़!

या अगर कोई फ़ाइल नहीं है तो क्या होगा? मान लीजिए आपके पास एक जावा कंपाइलर है जो मानक इनपुट पर इनपुट ले सकता है। तो फिर कक्षा को "StandardInput" नाम देना होगा?

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


मैं इस बात से सहमत हूं कि आपको क्या कहना है, लेकिन मैं नहीं जानता कि यह विशेष रूप से इस प्रश्न का उत्तर देता है कि शायद इस हद तक कि नामकरण वास्तुकला के परिणामस्वरूप होने वाली कुछ समस्याओं को गैर-सार्वजनिक वर्ग के नामों से अलग करने की अनुमति देकर आसान बनाया जा सकता है। फ़ाइल नाम। Btw, केस-संवेदनशीलता के संबंध में, अगर मैं एक भाषा पाने रहे थे, किसी भी दायरे में थे Fooघोषित किया गया था, पहचानकर्ता FOO, foo, fOo, आदि सभी "अपरिभाषित" किया जाएगा, भले ही वे बाहरी स्कोप के भीतर मौजूद था। इस तरह के एक डिजाइन फ़ाइल नाम के लिए संवेदनशीलता मामले को समाप्त कर देगा।
सुपरकैट

3

इसके अलावा एक अन्य बिंदु जो कई बिंदुओं को याद करने के लिए याद किया जाता है, वह यह है कि publicघोषणा के बिना , जेवीएम को कभी नहीं पता होगा कि किन वर्गों की मुख्य विधि को लागू करने की आवश्यकता है। एक .java फ़ाइल में घोषित सभी वर्गों में सभी मुख्य विधियाँ हो सकती हैं, लेकिन मुख्य विधि को केवल सार्वजनिक रूप से चिह्नित वर्ग पर चलाया जाता है। HTH


0

जावा फ़ाइल के कारण एक से अधिक वर्ग हो सकते हैं, इसमें एक जावा फ़ाइल में दो वर्ग हो सकते हैं। लेकिन एक जावा फाइल में एक वर्ग होता है, जिसमें फ़ाइल नाम के समान वर्ग होता है, यदि इसमें एक सार्वजनिक वर्ग होता है।


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