एक जावा स्रोत फ़ाइल उस सार्वजनिक वर्ग के नाम को क्यों सहन करती है जिसमें यह शामिल है?

Question

मैं जावा सीखने वाला नौसिखिया हूं। जावा में हर स्रोत फ़ाइल में एक सार्वजनिक वर्ग होना चाहिए और उस स्रोत फ़ाइल का नाम उस सार्वजनिक वर्ग के समान होना चाहिए। इसके अलावा, कोई स्रोत फ़ाइल में दो सार्वजनिक कक्षाएं नहीं हो सकती हैं। यह प्रतिबंध क्यों है?

Comments

बारीकियों के बिना, यह एक ऐतिहासिक डिजाइन विरूपण साक्ष्य है जिस तरह से जावा को इंजीनियर किया गया था। हाल ही में डिज़ाइन की गई भाषाएँ, जैसे C #, जबकि जावा के समान, यह प्रतिबंध नहीं है।

— गहूआ

क्या यह सर्वोत्तम प्रथाओं को लागू करने के लिए नहीं है? मुझे लगा कि यही एकमात्र कारण था। C # में, आपके पास तकनीकी स्तर पर यह प्रतिबंध नहीं है, लेकिन फिर भी StyleCop शिकायत करेगा कि क्या फ़ाइल का नाम और वर्ग का नाम मेल नहीं खाते हैं या यदि आपके पास एक ही फ़ाइल में कई कक्षाएं हैं। विजुअल स्टूडियो भी क्लास-फाइल रिलेशन को काफी प्रोत्साहित कर रहा है (क्लास डायग्राम जो आपके लिए फाइल बनाते हैं, या जब आप .cs फ़ाइल का नाम बदलते हैं, तो विजुअल स्टूडियो आपसे पूछता है कि क्या आप क्लास का नाम भी रिफैक्ट करना चाहते हैं)।

— आर्सेनी मूरज़ेंको

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

— पॉल टॉम्बलिन

@gahooa यह एक डिजाइन विरूपण साक्ष्य नहीं है, यह एक जानबूझकर डिजाइन निर्णय है। इससे कई चीजें बहुत आसान हो जाती हैं।

Grep का उपयोग करने के बारे में क्या ?

— उपयोगकर्ता

Answer 1

उनके एक जावा विशेषज्ञ समाचार पत्र में, हेंज काबुत्ज़ ओक भाषा विनिर्देशों के माध्यम से खोदता है । वह लिखता है:

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

यह एक ऐसा प्रश्न है जो मुझसे अक्सर मेरे पाठ्यक्रमों के दौरान पूछा जाता है। अब तक मेरे पास इस सवाल का अच्छा जवाब नहीं था। खंड 1 में, हम पढ़ते हैं: "हालांकि प्रत्येक ओक संकलन इकाई में कई वर्ग या इंटरफेस हो सकते हैं, प्रति संकलन इकाई में अधिकांश एक वर्ग या इंटरफ़ेस सार्वजनिक हो सकते हैं"।

साइडबार में यह समझाता है कि क्यों: "यह प्रतिबंध कंपाइलर द्वारा अभी तक लागू नहीं किया गया है, हालांकि यह कुशल कुशल आयातकों के लिए आवश्यक है"

यह बहुत स्पष्ट है - जैसे कि ज्यादातर चीजें डिज़ाइन के कारणों को जानने के बाद - संकलक को सभी संकलन इकाइयों (.java फ़ाइलों) के माध्यम से एक अतिरिक्त पास बनाना होगा ताकि यह पता लगाया जा सके कि कक्षाएं कहाँ थीं, और यह संकलन को और भी धीमा कर देगा। ।

http://www.javaspecialists.eu/archive/Issue055.html

Comments

मामूली तेजी से संकलन करने के लिए ? वास्तव में? इसलिए नहीं कि यह आपके कोड को अधिक व्यवस्थित बनाता है? मुझे अत्यधिक संदेह है कि यह सही उत्तर है।

— ब्लूराजा - डैनी पफ्लुगुफ्ट

@ BlueRaja-DannyPflughoeft 1998 में, मुझे यकीन है कि यह एक बहुत बड़ा अंतर है

— TheLQ

Answer 2

कारण मैं सोच सकता हूं

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

Comments

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

— सुपरकैट