कई साल पहले जब मैं यूनी में था तो उन्होंने इंटरफेस के सामने एक राजधानी I (I) डालने के लिए कहा। क्या यह अभी भी एक सम्मेलन है क्योंकि मैं कई इंटरफेस देखता हूं जो इसका पालन नहीं करते हैं।जावा इंटरफेस के सामने एक राजधानी 'मैं' डालकर
नहीं, यह सम्मेलन नहीं है। कम से कम यह जेडीके के भीतर नहीं है। उस ने कहा, अगर आपकी दुकान में यह एक सम्मेलन के रूप में है, भले ही यह बाहर अभ्यास न हो, मैं सुझाव दूंगा कि आप सूट का पालन करें। सम्मेलनों के संबंध में एक टीम के भीतर स्थिरता रखना अधिक महत्वपूर्ण है।
यह आमतौर पर जावा में नहीं किया जाता है - यह एक सी #/नेट चीज है।
व्यक्तिगत रूप से, मैं इसे नापसंद करता हूं क्योंकि मुझे लगता है कि यह जानकारी लीक हो जाती है जिसे लीक नहीं किया जाना चाहिए। कोड को अज्ञात लिखा जाना चाहिए कि किसी ऑब्जेक्ट को किसी इंटरफ़ेस के माध्यम से या सीधे क्लास एपीआई के माध्यम से संभाला जा रहा है या नहीं।
यह निश्चित रूप से .NET सम्मेलन है, और माइक्रोसॉफ्ट यह .NET बेस क्लास लाइब्रेरी में अपने स्वयं के इंटरफेस के साथ करता है। यह जावा सम्मेलन था जब मैंने जावा किया था, और कल्पना नहीं कर सकता कि यह बदल गया है, हालांकि मैं जावा के साथ अद्यतित नहीं हूं।
सी ++ में एक तरफ के रूप में हम हमेशा 'मैं' के साथ उपसर्ग करने के लिए भी उपयोग करते थे और वास्तव में हम हमेशा 'सी' वाले वर्गों को उपसर्ग करने के लिए उपयोग करते थे। हमने इस 'सी' सम्मेलन को .NET तक नहीं ले लिया।
यह गलत है - यह कभी भी जावा प्रोग्रामर के बीच एक सामान्य सम्मेलन होने के करीब नहीं रहा है ... शायद आपका मतलब था "यह जावा सम्मेलन नहीं था ..." ?? –
फिर मैं सही खड़ा हूं। मुझे लगता है कि यह कुछ ऐसा था जो हमने हमेशा किया था और मुझे लगता है कि यह सम्मेलन था। – MrLane
यह एक परिचित प्रोग्रामिंग सम्मेलन है, लेकिन इसका प्रसार API पर निर्भर करता है। उदाहरण के लिए, आमतौर पर जावा मानक लाइब्रेरी का पालन नहीं किया जाता है, जहां संग्रह जैसी चीजें इंटरफेस होती हैं, लेकिन उन्हें उनकी गणितीय अवधारणाओं के रूप में नामित किया जाता है। दूसरी ओर, ग्रहण जैसे कुछ महत्वपूर्ण एपीआई लगातार इसका उपयोग करते हैं।
उपसर्ग का उपयोग करने के खिलाफ मैंने एक तर्क सुना है कि एक अनिवार्य रूप से नामकरण योजना में एक भाषा मुद्दा (यानी, इंटरफेस और कक्षाओं की डिस्कोथॉमी) रख रहा है। दूसरा यह है कि "सार्वजनिक एपीआई में सबकुछ एक इंटरफ़ेस होना चाहिए, न कि किसी भी वर्ग में"। चूंकि इंटरफ़ेस को लागू करने वाले कई वर्गों को "XImpl" नाम दिया गया है, इसलिए कोई तर्क दे सकता है कि यह अनावश्यक हो सकता है। हालांकि, अगर उपसर्ग केवल मार्कर है तो उपसर्ग का उपयोग कर सकते हैं।
ग्रहण एपीआई? – Woot4Moo
@ Woot4Moo: क्या आप बहस कर रहे हैं कि यह महत्वपूर्ण नहीं है, या यह एक एपीआई नहीं है? वे निश्चित रूप से इसे एक एपीआई के रूप में संदर्भित करते हैं। – Uri
मैंने एपीआई नामक ग्रहण कभी नहीं सुना है। मैंने सुना है कि इसे एक आईडीई और यहां तक कि एक एसडीके कहा जाता है (जो सबसे अच्छा संदेह है) – Woot4Moo
जावा में सम्मेलन "सक्षम" में अपने इंटरफेस को आजमाकर समाप्त करना है। Serializable, क्लोनेबल, और इतने पर। .NET में वे "मैं" से शुरू होते हैं।
मैं आपकी भाषा के भीतर मानक दृष्टिकोण के साथ रहूंगा (यानी "सक्षम" एक्सटेंशन आज़माएं)। मैं सॉफ़्टवेयर बंदर से असहमत हूं कि यह "लीक की जानकारी को लीक नहीं किया जाना चाहिए"। यह नाम ठीक है कि यह नाम है कि यह किस प्रकार की बात है, IMHO।
बस सूची की तरह ... ओह प्रतीक्षा करें – Woot4Moo
मुझे नहीं लगता कि वास्तव में एक "सक्षम" एक्सटेंशन है। यह इंटरफेस के नामकरण सम्मेलन के आधार पर एक ऑपरेशन (उदाहरण के लिए, श्रोता, विज़िटर इत्यादि) – Uri
के बजाय विशेषण या भूमिका बनाने के बारे में अधिक है, जो कुछ सूचीबद्ध करने में सक्षम है, वह सूचीबद्ध होगा या ible यह सुनिश्चित नहीं करेगा कि यह कौन सा है ब्ली के साथ समाप्त होता है :) – Woot4Moo
यह ग्रहण फ्रेमवर्क में काफी उपयोग किया जाता है। यह व्यक्तिगत परियोजना शैलियों पर निर्भर करता है, लेकिन यह मानक सम्मेलन नहीं है। हालांकि, यह निश्चित रूप से कुछ मामलों में कोड रखरखाव और खोज में मदद कर सकता है।
मैं, इस तरह की चीज को नापसंद करता हूं। मैंने एक जावा उत्पाद के साथ काम किया जिसने इसे किया और यह गड़बड़ कर रहा था।
आखिरकार इस तरह की चीज 1 9 50 के दशक में फोरट्रान -1 से होती है जब मैं, जे, के, ... मैं भूल जाता हूं कि स्वचालित रूप से पूर्णांक कहां था और बाकी वर्णमाला वास्तविक (फ़्लोटिंग-पॉइंट) था।
मुझे लगता है कि मेरे पास कम से कम 3 मूक प्रशंसकों हैं। आपकी पसंद के लिए * कोई * कारण *? – EJP
मुझे लगता है कि यह "नफरत" शब्द है और तथ्य यह विषय और व्यक्तिपरक है। (पीएस: मैंने तुम्हें कम नहीं किया) – chburd
Blimey। एक शब्द के लिए 4 डाउनवोट्स और अन्य 46 पर शून्य ध्यान जो ऐतिहासिक तथ्य हैं। और मैं विवाद करता हूं कि यह विषय-वस्तु है। – EJP
इंटरफेस पर "आई" उपसर्ग का उपयोग करना कुछ COM स्थापित है (.NET ने अभी इस सम्मेलन को विरासत में मिला है) और जावा में एक मानक नहीं है। सूर्य द्वारा विकसित किसी भी जेडीके या अन्य कोड को देखें और आपको एक उपसर्ग नहीं दिखाई देगा। और यह केवल सूर्य ही नहीं है, अधिकांश जावा प्रोजेक्ट I उपसर्ग का उपयोग नहीं करते हैं। जावा मानक होने से बहुत दूर, मैं उपसर्ग जावा दुनिया के कुछ कोनों में अपनाया गया एक विचलन है।
एलओएल। समझाने की देखभाल क्यों? –
मैं उल्लेख करना है कि अन्य तरीके से, एक इंटरफेस की एक वास्तविक कार्यान्वयन, आप पोस्टफ़िक्स Impl या impl (example) नाम की एक पूरी पैकेज मिल सकता है चाहता था।
लेकिन यह वैसे भी एक मानक नहीं है।
@jax: +1 ... ऐसी दुनिया में जहां आप ओओए/ओओडी से ओओपी में अनुवाद करते हैं, तो जो कुछ मायने रखता है वह अव्यवस्था है। मैं बहुत भाग्यशाली होता हूं और कहीं काम करता हूं जहां * प्रत्येक * अमूर्तता को एक इंटरफेस द्वारा परिभाषित किया जाता है (यह केवल भाग में पैदा होता है - न केवल इस तथ्य से कि ओओए/डी अनुवादक होने के नाते, हम हर समय कई विरासत का उपयोग कर रहे हैं, और जावा के तहत जिसका अर्थ इंटरफ़ेस + प्रतिनिधिमंडल है)। हम इंटरफ़ेस नामों के सामने 'I' नहीं डालते हैं, हालांकि हम * हर * कक्षा कार्यान्वयन के बाद 'इम्प्ल' डालते हैं, यह सुनिश्चित करने के लिए कि ये कार्यान्वयन विवरण हैं और कभी भी "प्रोग्राम नहीं किया जाना चाहिए"। – SyntaxT3rr0r
मैं इसका उपयोग करने की अनुशंसा नहीं करता। आप कभी नहीं जानते कि आपका इंटरफेस एक दिन अमूर्त वर्ग बन गया है या नहीं। फिर आपको प्रत्येक एकल उपयोग का नाम बदलना होगा या उपसर्ग के साथ बदसूरत नामित अमूर्त वर्ग के साथ रहना होगा।
(स्रोत: रॉबर्ट सी मार्टिन - फुर्तीली सॉफ्टवेयर विकास: सिद्धांत, पैटर्न और आचरण)
यह अमूर्त वर्ग नहीं बन सकता है, क्योंकि यह कोड तोड़ देगा। आप "सार तत्व लागू नहीं कर सकते"। चूंकि आप कक्षा का नाम बदल नहीं सकते हैं, इसलिए आप "उपकरण" को "विस्तार" में बदल नहीं सकते हैं। – IAdapter
ठीक है, मेरी गलती। सी # के साथ उलझन में आ गया जहां आप विस्तार और लागू दोनों के लिए ":" का उपयोग करते हैं। –
@ 01 दूसरी तरफ समान रूप से महत्वपूर्ण है। यदि उसके पास एक अमूर्त वर्ग है जिसे वह एक इंटरफ़ेस बनाने का निर्णय लेता है, तो उसे या तो चुने हुए सम्मेलन से दूर कदम उठाना होगा और मुझे नोटेशन के बिना एक इंटरफेस होगा (ठीक है, अपने और सभी मानक वाले में से एक) और मुझे नोटेशन के साथ आराम करें (या कोड तोड़ देगा)। – Fredrik
कोडिंग शैली इस तरह की हंगेरी संकेतन कहा जाता है, क्योंकि यह माइक्रोसॉफ्ट पर चार्ल्स साइमोनयी द्वारा आविष्कार किया गया था, जो हंगेरियन होता है। हंगेरियन नोटेशन का उद्देश्य अर्थपूर्ण जानकारी को एन्कोड करना है जिसे टाइप सिस्टम के अंदर पहचानकर्ता नामों में व्यक्त नहीं किया जा सकता है।
हालांकि, जावा के प्रकार प्रणाली इंटरफेस के बीच भेद पूरी तरह से सक्षम है (सिर्फ एक वर्ग के साथ extend एक करने की कोशिश), सार वर्गों (सिर्फ एक दृष्टांत करने की कोशिश) और वर्गों (बस implement एक करने की कोशिश), और इसलिए सबसे कर रहे हैं IDEs। इसलिए, इस तरह से हंगेरियन नोटेशन का उपयोग पूरी तरह से बेकार है।
जहां तक मुझे पता है, यह कभी भी एक सम्मेलन नहीं रहा है, और यह निश्चित रूप से अब नहीं है। कम से कम जावा समुदाय में। (कुछ जावा प्रोजेक्ट्स हैं जो इसका उपयोग करते हैं, हालांकि इसका उपयोग कभी-कभी सी ++ में भी किया जाता है, लेकिन वहां यह समझ में आता है, क्योंकि सी ++ में इंटरफ़ेस जैसी कोई चीज़ नहीं है, इसलिए आपको उन्हें चिह्नित करने का कोई तरीका होना चाहिए। इसका उपयोग सीएलआई पर भी किया जाता है, जहां जावा में उसी कारण के लिए यह बिल्कुल समझ में नहीं आता है।)
क्या आपके पास कोई संदर्भ है जहां वे एचएन का यह हिस्सा बनाते हैं? मेरी दुनिया में एचएन ज्यादातर चर नामों पर प्रयोग किया जाता है, नामों का प्रकार नहीं। – Fredrik
यह संभावना है कि व्याख्याताओं ने उस भाषा से उस सम्मेलन को उठाया जो उन्होंने पहले इस्तेमाल किया था और बस माना कि यह जावा सम्मेलन भी था और इसे इस तरह सिखाया। – David
यह मजाकिया है कि माइक्रोसॉफ्ट ने लगभग हर चीज के लिए हंगेरियन नोटेशन से दूर किया लेकिन फिर भी उन्हें लगता है कि उन्हें यह नाम देखकर आपको बताने की जरूरत है कि यह एक इंटरफ़ेस है। –
कुछ जावा पुस्तकालयों में यह काफी आम है (उदाहरण के लिए, ग्रहण एसडीके) – Uri