जावा स्रोतों में एक दूसरे के अंदर इतने सारे फ़ोल्डर्स क्यों हैं?

Question

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

उदाहरण के लिए: https://github.com/halfninja/android-dragcontrol3d/tree/master/src/uk/co/halfninja/android शायद सबसे खराब उदाहरण नहीं है यही कारण है कि है, लेकिन वहाँ दो फ़ोल्डर्स "ब्रिटेन" और "सह" है कि बस मतलब नहीं है कर रहे हैं। मैं इसे केवल जावा स्रोतों में देखता हूं!

और उदाहरण minicraft के लिए: http://www.ludumdare.com/compo/ludum-dare-22/?action=preview&uid=398

import com.mojang.ld22.gfx.Font; 
import com.mojang.ld22.gfx.Screen; 
import com.mojang.ld22.gfx.SpriteSheet; 

क्यों सिर्फ लिख नहीं:

import gfx.Font; 
import gfx.Screen; 
import gfx.SpriteSheet; 

इतना क्लीनर है कि।

(मैं जावा में कभी नहीं प्रोग्राम किया गया है।)

Answer 1

ये वहाँ अन्य जार के साथ संघर्ष को रोकने के लिए कर रहे हैं। पैकेज नाम में कंपनी यूआरएल की तरह कुछ होने से यह किसी और के पैकेज और कक्षाओं के साथ संघर्ष न करने के लिए पर्याप्त अद्वितीय हो सकता है।

आपका उदाहरण एक अच्छा है, क्योंकि यह लगता है कि "gfx" को पैकेज नाम के रूप में और फ़ॉन्ट या स्प्राइट जैसी कक्षाओं के उपयोग के बारे में सोचने के लिए दो लोगों की कल्पना करना उचित लगता है। अब, यदि आप दोनों का उपयोग करना चाहते हैं, तो आप पैकेज और क्लास नाम के नाम से कैसे हो सकते हैं?

Answer 2

आपका रास्ता क्लीनर है, लेकिन ऐसा लगता है कि दुनिया में कोई और भी gfx नामक पैकेज बनाने जा रहा है, जो एक बहुत ही कमजोर धारणा है। अपने उलट डोमेन नाम को प्रीपेड करके, आप एक अनन्य नेमस्पेस बनाते हैं जो टकराव से बचाता है।

यह जावा प्रोग्रामिंग में व्यापक रूप से "साझा करने की संस्कृति" के साथ फिट बैठता है, जिसमें अनुप्रयोग आमतौर पर कई स्रोतों से बड़ी पुस्तकालयों को जोड़ते हैं।

Answer 3

जावा में, सम्मेलन आपके संगठन (आमतौर पर एक टीएलडी और कंपनी का नाम सहित) और परियोजना (जो कुछ और वर्ग जोड़ सकता है) की जानकारी के साथ आपके पैकेज (जो आपके कोड वाले फ़ोल्डर संरचना से संबंधित है) का नाम है।)।

इस तरह के अधिक विशिष्ट होने के कारण नामस्थानों की आकस्मिक रूप से एक दूसरे के साथ टकराने की संभावना कम हो जाती है।

Answer 4

यदि आप सभी के साथ कोड साझा करना चाहते हैं, लेकिन बिना किसी संघर्ष के सामान्य नामों का उपयोग करें। इसे डोमेन नाम (पिछला)

प्रत्येक व्यक्ति को gfx.Font नामक एक पैकेज लिखने के लिए अच्छा अभ्यास माना जाता है, तो आप उसी एप्लिकेशन में एक से अधिक संस्करणों का उपयोग करने में सक्षम नहीं होंगे।

आपको लगता है कि आपका कोड दुनिया के साथ साझा नहीं किया जाएगा (या यहां तक ​​कि साझा नहीं किया जाना चाहिए) इस मामले में, एक छोटी पैकेज संरचना सरल हो सकती है।

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

Answer 5

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

Answer 6

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

• कॉम = या तो इस या संगठन, सरकारी पैकेज के लिए जावा/javax
• Mojang = दूसरे भाग है कंपनी का नाम
• ld22 = तीसरे भाग आवेदन नाम है

: com.mojang.ld22 हिस्सा सिर्फ एक सम्मेलन है

Answer 7

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

Answer 8

यह लगभग नामस्थान है। 'नेमस्पेस' के साथ, आप अलग-अलग पैकेज/फ़ोल्डरों में स्थित एक ही नाम के साथ 2 कक्षाएं बना सकते हैं।

1) Namespace 2) Java Package 3) Java Package Naming Conventions

संपादित करें: हमें लगता है कि आप बना रहे हैं चलो यह नाम स्थान तर्क भी नीचे कुछ लिंक हैं 'पहुंच विशेषाधिकार, वगैरह वगैरह बनाने के लिए इस्तेमाल किया जा सकता एक नई परियोजना और कंपनियों/संगठनों - कॉमा और कॉमब से 2 ओपन सोर्स फ्रेमवर्क का उपयोग कर रहे हैं। साथ ही, मान लें कि कॉमए और कॉमब ने एक ही कक्षा नाम के साथ अपनी परियोजनाओं में एक कक्षा बनाई है। अब, जावा पैकेज नामकरण सम्मेलनों के साथ, हमारे पास com.comA.SomeClass और com.comB.SomeClass है। आप संघर्ष के बिना, अपनी कक्षा में दोनों वर्गों को आयात और उपयोग कर सकते हैं। यह सिर्फ एक साधारण उदाहरण है। इस नामकरण सम्मेलन से अन्य उपयोग भी हैं।