जावा में कोई 'सबक्लासेस-ओनली' एक्सेस मॉडिफायर क्यों नहीं है?


17

जावा में, विधियों के लिए चार उपलब्ध पहुँच संशोधक हैं:

public - कोई भी वर्ग इस पद्धति का उपयोग कर सकता है।

protected - एक ही पैकेज में कक्षाएं और किसी भी पैकेज में उपवर्ग इस पद्धति का उपयोग कर सकते हैं।

private - केवल यह वर्ग इस पद्धति का उपयोग कर सकता है।

no modifier ("पैकेज निजी") - एक ही पैकेज में केवल कक्षाएं इस पद्धति का उपयोग कर सकती हैं।

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

इसलिए मुझे इन उपयोगी तरीकों को सुपरक्लास में घोषित करना होगा publicया protected, जो उन्हें अन्य सभी वर्गों के लिए कम से कम पैकेज में उजागर करता है। हालांकि वे केवल उपवर्गों द्वारा उपयोग किए जाने के लिए हैं।

क्या subclasses-onlyजावा में एक्सेस मॉडिफायर नहीं है इसका कोई कारण है ? यह मुझे बहुत अजीब लगता है। क्या मैं कुछ भूल रहा हूँ?

इसके अलावा, एक subclasses-onlyएक्सेस संशोधक भी उपयोगी होगा जब आप केवल उपवर्गों के लिए चर को उजागर करना चाहते हैं। जो मुझे बहुत होता है।

जवाबों:


10

क्योंकि आप संरक्षित संशोधक का उपयोग करके उपवर्गों-केवल संशोधक का अनुकरण कर सकते हैं और यह सुनिश्चित कर सकते हैं कि केवल मूल वर्ग और उसके उपवर्ग एक ही पैकेज में हैं।

यह वास्तव में एक अच्छा अभ्यास है, क्योंकि पैकेज न केवल सामंजस्य के संदर्भ में बड़ी परियोजनाओं को व्यवस्थित करने में मदद करते हैं, बल्कि वे यह भी बताते हैं कि एक ही पैकेज में कक्षाओं में कुछ स्तर का युग्मन हो सकता है।


15
"और केवल माता-पिता वर्ग और उसके उपवर्गों को एक ही पैकेज में लागू करने के लिए" - अब, कोई ऐसा कैसे करेगा ?!
जिमीबी

1
और फिर आप केवल-पैकेज एक्सेस संशोधक का उपयोग नहीं कर सकते। और आपको पैकेज की एक मूर्खतापूर्ण राशि चाहिए। यह एक व्यावहारिक समाधान नहीं है।
user253751

13

जावा में मूल रूप से ऐसा एक संशोधक था। यह लिखा गया था private protectedलेकिन जावा 1.0 में हटा दिया गया था ।

मुझे लगता है कि एक निर्णय कॉल था कि अतिरिक्त जटिलता लागत के लायक नहीं थी।

प्रत्येक भाषा सुविधा में एक लागत होती है: इसे नए प्रोग्रामर को पढ़ाने में; प्रलेखन में; कंपाइलर, जेवीएम, और देव टूल्स में इसे लागू करने में; कार्यक्रम शुद्धता के बारे में तर्क में; भविष्य की भाषा के विकास में बाधा; और अधिक। भाषा सुविधाएँ एक दूसरे के साथ बातचीत करती हैं, संभवतः एन 2 इंटरैक्शन के साथ।

जावा भाषा युक्ति और वीएम युक्ति के माध्यम से जावा प्रोग्रामर कितने प्रतिशत पढ़ चुके हैं? मुझे यकीन है कि यह एक छोटा प्रतिशत है, जो समझने की क्षमता और इंजीनियरिंग उत्पादों के लिए एक सरल भाषा के लिए तर्क देता है, जिस पर हम निर्भर कर सकते हैं

private protectedसुविधा का लाभ छोटा था क्योंकि पैकेज प्रतिरूपकता की मुख्य इकाई है।


1
तो 1.0 से पहले जावा संस्करण था?
मार्क यिश्री

1
@MarkYisri जावा ने 1995 में सार्वजनिक अल्फा और बीटा रिलीज़ की थी, और उनके खिलाफ एक निष्पक्ष बिट कोड लिखा गया था।
डेविड मोल्स

4

चींटियों के नियंत्रण को एक काल्पनिक डेवलपर के साथ एक आवरण के परिणाम के रूप में माना जा सकता है जो आपकी कक्षा के साथ कक्षा के तरीकों और उचित कार्यों के बारे में काम कर रहा है ...

आप: कहते हैं कि आप एक्स करना चाहते हैं, आप विधि को कॉल करते हैंX .. DEV: मुझे और बताओ..क्या तर्क हैं?

यह सार्वजनिक है ...

You: इनसाइड doX I कॉल ... DEV: वाह, बहुत अधिक जानकारी, मुझे इस बारे में परवाह नहीं है। मैं सिर्फ यह जानना चाहता हूं कि इसका उपयोग कैसे करना है। और सुनाओ कुछ।

यह निजी है ...

You: जब उपवर्ग, मेरे पास doX और doY कॉल doIt होता है जो करता है .. DEV: हाँ, मैं उपवर्ग वाला हूँ, मुझे और बताओ ...

यह संरक्षित है ...

You: मैं एक घंटे में छुट्टी पर जा रहा हूं, मैं अगले 6 महीनों के लिए चला जाऊंगा। बॉस कहता है यह पिल्ला तुम्हारा है! अलविदा। DEV: रुको अभी मत जाओ, मुझे सब कुछ बताओ ...

यह पैकेज है।

You: विधि doItWhen केवल इस वर्ग द्वारा बुलाया जाता है और यह दस वर्षों में नहीं बदला है। यह ... DEV: वाह, हम 50 मिनट के लिए नीचे हैं। अगली संपत्ति, और तेजी से बात करें।

यह निजी संरक्षित है ...


3

यह पहले से मौजूद है। यह संरक्षित है।

पैकेज के भीतर कौन सी कक्षाएं मौजूद हैं, इस पर आपका नियंत्रण है। यदि पैकेज में कोई अन्य वर्ग नहीं है और किसी दिए गए चर या विधि को संरक्षित किया जाता है, तो यह 'केवल उपवर्ग' है।

उस ने कहा, एक बार फिर, आपके पास इस बात पर नियंत्रण है कि पैकेज के भीतर कौन सी कक्षाएं मौजूद हैं। आप संरक्षित विधियों या चर का उपयोग न करने के लिए चुना जा सकता है।


3
कुछ आरक्षित सिस्टम पैकेजों के अलावा, क्या मैं किसी भी पैकेज में क्लास नहीं जोड़ सकता, यहां तक ​​कि आप में से एक जो आप मुझे क्लास जोड़ने का इरादा नहीं रखते हैं?
डेविड मोल्स

@ डेविड IIRC हाँ, लेकिन यह आपको पैकेज फ़ील्ड को दूसरे JAR से एक्सेस नहीं करने देगा, भले ही आप इसे एक ही पैकेज में रखें, अगर यह दूसरे JAR में है तो आप इसे एक्सेस नहीं कर सकते। हालाँकि, यदि आप उसी JAR के भीतर का उल्लेख कर रहे हैं, तो हाँ, आप इसे एक्सेस कर सकते हैं, लेकिन यदि आप JAR को संशोधित करने में सक्षम हैं, तो आप एक्सेस मॉडिफायर को आसानी से बदल सकते हैं।
प्रिव्यू 22

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