क्या जावा पैकेज नाम कन्वेंशन त्रुटिपूर्ण है? [बन्द है]

28

डोमेन नाम को चारों ओर मोड़ने वाले जावा पैकेज नाम सम्मेलन से हम सभी परिचित हैं। यानी www.evilcorp.com, कन्वेंशन द्वारा, उन्होंने अपने जावा पैकेज को चुना com.evilcorp.stuff।

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

ओपनसोर्स की दुनिया में नाम परिवर्तन कम होता है इसलिए यह समझ में आता है। हालांकि यह मुझे लगता है कि (वाणिज्यिक / आंतरिक) सॉफ्टवेयर के कई टुकड़ों का शेल्फ जीवन संगठन बनाने की तुलना में बहुत लंबा है।

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

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

अन्य विचार?

java naming

— मार्टिन एलेस्टेन
स्रोत

2

We're all familiar with the Java package name convention of turning the domain name around.- um..no हम नहीं कर रहे हैं ... :)

— डॉ हैनिबल लेक्टर

8

@ श्री हनीबल लेक्चरर: बहुत ही सरल। जावा (साइट Java.com पर) उनके पैकेजों का नाम देता है com.java.etc.etc। Apache (साइट Apache.org पर) उनके पैकेजों को नाम देता है org.apache.etc.etc। आप पैटर्न देखें।

— डोपेलग्रेनेर

3

@ डॉ। हनीबल लेक्टर: Cf. docs.oracle.com/javase/tutorial/java/package/namingpkgs.html

— user359996

1

"ओपनसोर्स की दुनिया में कम नाम परिवर्तन होते हैं" - यहां तक कि यह एक समस्या है, अक्सर मैं ऐसे प्रोजेक्ट देखता हूं जो अब गिथब कहते हैं लेकिन उनके पैकेज के नाम से पता चलता है कि वे net.sourceforge.xxx या com के रिवर्स में हुआ करते थे। googlecode.xxx

— nafg

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

— जूल्स

23

मैं Microsoft को नेमस्पेस (.NET के पैकेज) के लिए दी गई सलाह को उद्धृत करने जा रहा हूं , जिसमें डोमेन नाम सम्मेलन नहीं है। मुझे लगता है कि यह जावा पैकेज के लिए भी अच्छी सलाह है, क्योंकि मुझे विश्वास नहीं है कि एक डोमेन नाम एक ठोस और स्थिर पहचान का प्रतिनिधित्व करता है।

एक नामस्थान नाम के लिए सामान्य प्रारूप निम्नानुसार है:

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

उदाहरण के लिए, Microsoft.WindowsMobile.DirectX।

अलग-अलग कंपनियों के नामस्थानों को एक ही नाम और उपसर्ग से रोकने के लिए एक कंपनी के नाम के साथ उपसर्ग नामस्थान करें।

किसी नामस्थान नाम के दूसरे स्तर पर एक स्थिर, संस्करण-स्वतंत्र उत्पाद नाम का उपयोग करें।

नामधारी पदानुक्रम में नामों के आधार के रूप में संगठनात्मक पदानुक्रम का उपयोग न करें, क्योंकि निगमों के भीतर समूह के नाम अल्पकालिक होते हैं।

नेमस्पेस नाम एक लंबे समय तक रहने वाला और अपरिवर्तनीय पहचानकर्ता है। जैसा कि संगठन विकसित होते हैं, परिवर्तनों को नाम स्थान को अप्रचलित नहीं बनाना चाहिए।

यदि आपकी कंपनी का नाम भी अस्थिर है, तो आप केवल उत्पाद के नाम से शुरुआत करना चाहते हैं।

— एलोन गुरलनाक
स्रोत

3

यदि कोई अन्य कंपनी आपके समान नाम वाली है तो Microsoft आपको क्या करने की सलाह देता है?

25

@

— थोरबजोरन

9

@ Thorbjørn: एक नेमस्पेस, एक डोमेन के विपरीत, किसी के पास नहीं है और न ही किसी के पास हो सकता है। यह केवल एक तार्किक विभाजन या कोड का वर्गीकरण है। आपके और उस अन्य कंपनी के बीच टकराव की संभावना शून्य तक पहुंच जाती है, जब तक कि दूसरी कंपनी भी उसी तकनीक में सॉफ्टवेयर विकसित करने के लिए नहीं होती है, और उसी तरह की पेशकश होती है (संक्षेप में - आपका एक प्रतियोगी)। उस स्थिति में, मैं RebBingo का सुझाव लेता हूं, जब तक कि आप एक प्रतिस्पर्धी कंपनी के साथ ठीक नहीं होते हैं, जिसका आपकी कंपनी के समान नाम है।

— एलोन गुरिलनेक

4

के रूप में में @ Thorbjorn के जवाब ने कहा, समस्या के लिए गारंटी नहीं है जावा नामकरण परंपरा को हल करती है भक्ति बल्कि गारंटी विशिष्टता । ध्यान दें कि Microsoft कन्वेंशन न तो गारंटी देता है ।

— user359996

4

@ user359996: जैसे मैंने कहा, मैं यह नहीं देखता कि सार्वभौमिक विशिष्टता एक समस्या है जिसे हल करने की आवश्यकता है। पारस्परिक रूप से अनन्य कोड आधारों में अद्वितीय होने के लिए आपको नामों की आवश्यकता क्यों होगी? और जावा की शैली इसकी गारंटी नहीं देती है, क्योंकि डोमेन नाम स्वामित्व हाथ बदल सकता है। एक डेवलपर जो jUtils.com का मालिक है, एक com.jutils विकसित कर सकता है। * पुस्तकालय जो कई उपयोग करता है, और फिर अपने डोमेन को एक पूरी तरह से अलग डेवलपर को बेचता है जो एक अलग com.jutils विकसित करता है। * पुस्तकालय जो लोकप्रिय भी है, लेकिन इसके साथ टकराव भी है। मौजूदा पुस्तकालय।

— एलोन गुरिलनेक

15

आप एक अलग समस्या के समाधान को देख रहे हैं, अर्थात् हम उस प्रोग्रामर X से कैसे बचते हैं और प्रोग्रामर Y एक ही पैकेज में फाइल लगाकर एक दूसरे के पैर की उंगलियों पर कदम रखते हैं।

"बस अपने डोमेन नाम को उल्टा करें" इसे एक सुरुचिपूर्ण तरीके से हल करें, क्योंकि आप तब बहुत निश्चित हैं कि यदि X और Y असंबंधित हैं तो वे समान पैकेज नाम स्थान नहीं चुनेंगे।

+1 "आप एक अलग समस्या का समाधान देख रहे हैं।"

— उपयोगकर्ता 359996

10

अधिवेशन त्रुटिपूर्ण नहीं है। लोग दोषपूर्ण हैं, जैसा कि आपने खुद को अच्छी तरह से चित्रित किया है।

मैं 2 लाभों के बारे में सोच सकता हूं:

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

— back2dos
स्रोत

7

रिवर्स डोमेन नाम का उपयोग नाम टकराव से बचने के लिए किया गया था, क्योंकि विभिन्न संगठन अपने पुस्तकालयों में एक ही वर्ग के नाम का उपयोग करते हैं। यह एक सरल समाधान है और ऑफ आंसर में कुछ कमियां हैं (उदाहरण के लिए, समान कक्षाओं में कक्षाओं के लिए नाम टकरावों के बारे में क्या)।

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

लेकिन विकल्पों पर विचार करें। उदाहरण के लिए, आप लॉगफ़ैक्ट्री के लिए दो पूरी तरह से योग्य वर्ग नामों की तरह कैसे होंगे:

a50e8400_e29b_41d4_a716_446655440000.LogFactory
f47ac10b_58cc_4372_a567_0e02b2c3d479.Logfactory

या

org.apache.commons.logging.LogFactory
com.evilcorp.logging.LogFactory

इसलिए, मेरे विचारों में, जब तक आप इसे पसंद करते हैं, तब तक इसका उपयोग करें, जिसमें सामान्य ज्ञान और आपके पुस्तकालय के उपयोगकर्ताओं के लिए एक विचार शामिल है।

4

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

यह परिदृश्य मुझे फिट बैठता है, क्योंकि स्रोत कोड आमतौर पर उत्पाद का एक महत्वपूर्ण हिस्सा नहीं होता है, अर्थात परियोजनाएं आमतौर पर एक बंद-स्रोत, स्वामित्व प्रणाली होती हैं। हालांकि, ओपन-सोर्स प्रोजेक्ट्स में जहां स्रोत कोड उत्पाद है, यह संभव नहीं है।

— SWeko
स्रोत