जावा में,क्या ऑब्जेक्ट डेटा को समाहित करते हैं ताकि एक ही कक्षा के अन्य उदाहरण डेटा तक पहुंच न सकें?
क्या ऑब्जेक्ट डेटा को समाहित करते हैं ताकि एक ही कक्षा के अन्य उदाहरण भी डेटा तक पहुंच सकें? केवल तभी जब कीवर्ड "निजी" का उपयोग किया जाता है? जावा में "एक्सेसर विधियां" क्या हैं - getName() जैसी विधियां?
धन्यवाद
मैं एक वस्तु एक और करने के लिए उपयोग होने के मामले में यह के बारे में सोच के लिए करते हैं नहीं है, बल्कि क्या कोड किसी वस्तु में कौन-सा डेटा तक पहुँच गया है।
कक्षा में (और सी #, बीटीडब्ल्यू) कोड में कक्षा के भीतर एक ही कक्षा के किसी भी वस्तु के निजी सदस्यों तक पहुंच है। फिर आपके पास पैकेज/असेंबली एक्सेस और सार्वजनिक पहुंच है।
मुश्किल एक सुरक्षित पहुंच है, जो उप-वर्गों में कोड तक पहुंच प्रदान करता है - लेकिन यह लक्ष्य ऑब्जेक्ट पर निर्भर करता है: आपको केवल किसी ऑब्जेक्ट के संरक्षित सदस्यों तक पहुंचने की अनुमति है यदि यह एक उदाहरण है कोड के स्थान या कुछ उप-वर्ग के रूप में टाइप करें - भले ही यह हो, तो मूल वर्ग द्वारा का खुलासा किया गया हो। तो उदाहरण के लिए, मान लीजिए आप था:
class Parent
{
protected int x;
}
class Child1 extends Parent
class Child2 extends Parent
class Grandchild extends Child1
फिर Child1 कोड के भीतर, आप Parent.x केवल वस्तुओं जो (संकलन समय पर) में जाना जाता है Child1 या Grandchild के उदाहरण होने के लिए उपयोग कर सकते हैं। उदाहरण के लिए, आप new Parent().x या new Child2().x का उपयोग नहीं कर सके।
नहीं, निजी क्षेत्रों अन्य उदाहरण से भी (एक ही कक्षा के एक तरीके के अंदर), पहुँचा जा सकता है।
उन्हें उप-वर्गों से एक्सेस नहीं किया जा सकता है, हालांकि, एक ही उदाहरण के भीतर भी नहीं।
आप अपनी कक्षा में फ़ील्ड तक पहुंचने के लिए "बाहरी" कोड को अनुमति देने के लिए गेटटर विधियां प्रदान करते हैं। चूंकि यह आपके ऊपर निर्भर करता है कि आप कौन से गेटर्स प्रदान करते हैं, आप उन्हें कितना दृश्यमान करते हैं, और उन्हें कैसे कार्यान्वित किया जाता है, आप इस बात पर बहुत अधिक नियंत्रण कर सकते हैं कि डेटा का उपयोग कौन कर सकता है और कैसे।
ध्यान दें कि फ़ील्ड होने की वास्तव में आवश्यकता नहीं है यदि getName है: यह पूरी तरह से गेटटर के कार्यान्वयन तक है जहां वह डेटा आता है।
भले ही गेटर (या सेटर) सिर्फ एक निजी क्षेत्र को लपेटता है, फिर भी यह सेटर्स और गेटर्स (प्रत्यक्ष क्षेत्र पहुंच की अनुमति देने के विपरीत) की अच्छी शैली है।
getName() नाम (wheather फ़ील्ड या कुछ अन्य "चीज़") वापस करना चाहिए।
भले ही कोई फ़ील्ड/विधि 'निजी' है, फिर भी इसे प्रतिबिंब के माध्यम से एक्सेस/इनवॉक्ड किया जा सकता है जब तक कि आप एक कस्टम सुरक्षा प्रबंधक स्थापित नहीं करते हैं जो इसे अस्वीकार करता है।
आप जेएनआई के माध्यम से फ़ील्ड तक पहुंच सकते हैं। किसे पड़ी है? (इसके अलावा, सुरक्षा प्रबंधक को कस्टम होने की कोई आवश्यकता नहीं है।) –
ठीक है, हाँ। यदि संभव हो तो प्रतिबिंब से बचने के कारणों में से एक यही कारण है। – sleske
encapsulation का विचार अलग-अलग इकाइयों के कार्यान्वयन को स्वतंत्र रूप से भिन्न करने की अनुमति देना है। हालांकि हम वस्तुओं के बारे में बात करते हैं, encapsulation के लिए हम वास्तव में कोड की एक इकाई का मतलब है। कक्षा-आधारित भाषाओं में, कोड की इकाई आमतौर पर [बाहरी] कक्षा होती है।
यह भी होता है कि बाइनरी ऑपरेशंस (जैसे बराबर) उसी वर्ग के भीतर पहुंच के बिना दाफ्ट बन जाते हैं।तो निजी माध्यम [बाहरी] वर्ग के लिए निजी है, एक ही उदाहरण के लिए एक ही कक्षा में निजी नहीं है।
accessor तरीकों आम तौर पर कुछ भी लेकिन साधारण मूल्य वस्तुओं (केवल टिककर खेल) पर बुरा डिजाइन संकेत मिलता है। ऑब्जेक्ट्स के पास डेटा का गूंगा संग्रह होने के बजाय व्यवहार होना चाहिए। उस कोड को ले जाएं जो गेटर्स का उपयोग किसी विधि पर है जो ऑब्जेक्ट पर सार्थक है। दिल पर हाथ, 99% समय के गेटर्स सिर्फ एक फील्ड मूल्य लौटते हैं। यदि आप गेटटर और सेटर जोड़ने जा रहे हैं तो फ़ील्ड निजी बनाने में अपेक्षाकृत कम मूल्य है।
जावा में "एक्सेसर विधियां" क्या हैं - getName() जैसी विधियां?
हाँ - getFoo() और setFoo() एक "संपत्ति" foo नामित के लिए एक्सेसर तरीके हैं - इस JavaBeans विनिर्देश का हिस्सा है। कारण है कि इन सार्वजनिक क्षेत्रों से अधिक पसंद कर रहे हैं कि वे, अतिरिक्त बहीखाता (व्युत्पन्न क्षेत्रों की गणना की तरह) (जैसे फेंक एक PropertyVetoException जब मूल्य है और सेट मूल्यों की मान्यता आप केवल एक गेटर (संपत्ति केवल पढ़ने के लिए कर रही है) की अनुमति है स्वीकार्य नहीं है)।
पूरी बात मूल जीयूआई उपकरण है कि आप रेखांकन कॉन्फ़िगर और आदेश "अनुप्रयोगों के निर्माण करने के लिए" में JavaBeans गठबंधन करने की अनुमति होगी के साथ इस्तेमाल किया जा करने का इरादा था। यह काफी हद तक एक पाइप सपना बन गया, लेकिन जावाबीन और गुणों की अवधारणा नियमित कोडिंग के लिए उपयोगी साबित हुई और व्यापक रूप से फैल गई।
बहुत से लोग अवधारणा गलत और विश्वास है कि "कैप्सूलीकरण" बस के बजाय निजी संपत्तियों के लिए setters और getters लेखन उन्हें सार्वजनिक करने का मतलब है - और फिर हक है कि मूर्खतापूर्ण विचार करें। Encapsulation का अर्थ है के सभी पर कड़े नियंत्रित तरीके को छोड़कर कक्षा के आंतरिक कार्य को उजागर नहीं करना। अच्छे ओओ डिज़ाइन में, आपको कक्षा में बहुत से तरीके और बहुत कम सेट विधियां नहीं मिलनी चाहिए।
क्या ऑब्जेक्ट डेटा को समाहित करते हैं ताकि एक ही कक्षा के अन्य उदाहरण डेटा तक पहुंच न सकें?
निश्चित रूप से, यदि आप स्थिर सदस्यों का उपयोग नहीं कर रहे हैं। this link से
निकालें:
कभी कभी, आप चर कि सभी वस्तुओं के लिए आम हैं करना चाहते हैं। यह स्थिर संशोधक के साथ पूरा किया जाता है। जिन क्षेत्रों में उनकी घोषणा में स्थैतिक संशोधक है उन्हें स्थिर फ़ील्ड या कक्षा चर कहा जाता है
ठीक है, इसे नाम वापस करना चाहिए। चाहे वह नाम के नाम पर रखा गया हो या चाहे वह किसी अन्य ऑब्जेक्ट आदि से लिया गया हो, एक कार्यान्वयन विवरण है। –