गेटर और सेटर (एक्सेसर) फ़ंक्शंस के माध्यम से निजी चरों तक पहुंचने का क्या मतलब है?

Question

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

हालांकि, मैं हमेशा निजी बनाये गये चर देखता हूं, और उसके बाद उस मूल्य को पुनर्प्राप्त करने के लिए उपयोग किए जाने वाले गेटर और सेटर फ़ंक्शन (कभी-कभी उस चर के लिए पॉइंटर भी!)। उदाहरण के लिए int a सार्वजनिक पहुंच को रोकने के लिए निजी है, लेकिन फिर getA() और setA() उन्हें सीधे पहुंच की अनुमति देता है।

तो गेट फ़ंक्शन और सेटर फ़ंक्शन निजी होने के बिंदु को नकारें? मेरा मतलब है कि एक्सेसर फ़ंक्शन के साथ निजी चर सार्वजनिक चर के समान हैं, केवल उन्हें बदलने के लिए कोड। (object.variable vs object.getVariable())

क्या कोई कारण है कि लोग एक्सेसर फ़ंक्शंस के साथ चर बनाते हैं? क्या इसे सार्वजनिक बनाने की तुलना में कोई फायदे हैं?

मैं सामान्य रूप से प्रोग्रामिंग के बारे में बात कर रहा हूं, लेकिन ज्यादातर सी भाषाओं में (यानी सी, सी ++, सी #, ओबीजे-सी)।

Answer 1

यहां कुंजी शब्द और टैग "encapsulation" है। आप a के ब्योरे को छुपा रहे हैं, जबकि अभी भी इसे प्रयोग योग्य बनाते हैं। मुझे पहले से सूचीबद्ध कारणों को पसंद है, और भी बहुत कुछ हैं। यहां एक और है, आप डिबगिंग कर रहे हैं, और आपको a का गलत मान मिल गया है। यदि a सार्वजनिक है, तो आपको हर जगह a एक्सेस करना होगा। यदि a एक सेटर विधि के साथ निजी है, तुम्हें पता है केवल जगह a बदल गया होगा setA() के लिए एक कॉल में है - एक ब्रेकपाइंट डाल करने के लिए एक महान जगह हो सकता है;)

Answer 2

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

इसका यह भी अर्थ है कि आप आसानी से ब्रेकपॉइंट सेट कर सकते हैं यह देखने के लिए कि यह कब उपयोग होता है (हालांकि अधिकांश भाषाओं/डिबगर्स के पास कुछ प्रकार के डेटा ब्रेकपॉइंट होते हैं)।

Answer 3

शायद आप लाइब्रेरी के अगले संस्करण में कुछ चेक जोड़ना चाहते हैं (या किसी को मूल्य पढ़ने पर कुछ करने के लिए), और यदि वैरिएबल वर्तमान संस्करण में सार्वजनिक होगा, तो पुस्तकालय संस्करण को अपग्रेड करने के लिए लागत होगी बहुत सारा काम।

Answer 4

कक्षा व्यवहार को परिभाषित करता है और सदस्यों राज्य कर रहे हैं ऑब्जेक्ट का ... इसलिए एक सेटर और गेटटर होने से कक्षा के encapsulation व्यवहार को दूसरों को ऑब्जेक्ट स्थिति ढूंढने/बदलने की अनुमति देता है।

दूसरे शब्दों में अंतर यह है कि अंतर आपके पड़ोसी को आपके घर में आने और वह जो चाहता है उसे ले लेना (कक्षा में सभी वस्तुएं सार्वजनिक करना) .... या यह सुनिश्चित करना कि पड़ोसी मुझसे पूछता है कि वह क्या चाहता है और मैं उसे देता हूं (एक गेटर/सेटर रखना ....)

Answer 5

encapsulation क्यों आवश्यक था? ओओपी क्यों जरूरी था? क्या हम आज क्या कर रहे हैं करने में सक्षम सीएस प्रोग्रामिंग भाषा? इसे yourslef से पूछें। या यदि आपने लाखों लाइनों के कोड वाले विशाल सिस्टम पर काम किया है। और आपके द्वारा उपयोग किए जाने वाले सभी कार्यक्रमों के प्रत्येक मॉड्यूल से उपलब्ध एक महत्वपूर्ण डेटा संरचना के सार्वजनिक चर थे।

Answer 6

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

मुझे उत्तर मिलता है जब मैं वास्तविक व्यवसाय एप्लिकेशन को लागू करना शुरू करता हूं।

के एक वर्ग के छात्र जो छात्र नाम शामिल पर विचार करें, रोल नहीं, 3 विषयों

के निशान

Class Student { 

    private int rollno; 
    private int java_marks; 
    private int cpp_marks; 
    private int unix_marks; 
    private int percentage; 


    public int getJava_marks() { 
     return java_marks; 
    } 
    public void setJava_marks(int java_marks) { 
     if (java_marks > 100) { 
      System.out.println("Marks value should be less than 100"); 
      //throw exception 
     } 
     this.java_marks = java_marks; 
    } 
    public int getCpp_marks() { 
     return cpp_marks; 
    } 
    public void setCpp_marks(int cpp_marks) { 
     if (cpp_marks > 100) { 
      System.out.println("Marks value should be less than 100"); 
      //throw exception 
     } 
     this.cpp_marks = cpp_marks; 
    } 
    public int getUnix_marks() { 

     return unix_marks; 
    } 
    public void setUnix_marks(int unix_marks) { 
     if (unix_marks > 100) { 
      System.out.println("Marks value should be less than 100"); 
      //throw exception 
     } 
     this.unix_marks = unix_marks; 
    } 
    public int getPercentage() { 
     this.percentage = (this.cpp_marks + this.unix_marks + this.java_marks) /3; 
     return percentage; 
    } 

    public int getRollno() { 
     return rollno; 
    } 
    public void setRollno(int rollno) { 
     this.rollno = rollno; 
    } 

} 

यहाँ क्योंकि

1. मान्यकरण 2 कारणों से निजी चर बनाने: यदि कोई उपयोगकर्ता प्रदान करता है अंकों के लिए अमान्य मान तो छात्र ऑब्जेक्ट को अमान्य डेटा के साथ नहीं बनाना चाहिए और उपयुक्त त्रुटि/अपवाद फेंकना चाहिए। अंकों के मामले में सार्वजनिक varibles उपयोगकर्ता उनके लिए कोई मूल्य निर्धारित कर सकते हैं, इसलिए मैंने सुनिश्चित किया कि प्रत्येक छात्र ऑब्जेक्ट को सही डेटा रखने के लिए सत्यापन/सुरक्षा जोड़ा गया है।

2. सुरक्षा प्रतिशत के मामले में, उपयोगकर्ता अपना प्रतिशत निर्धारित नहीं कर सकता है। प्रतिशत की गणना की जाती है और आंतरिक रूप से सेट की जाती है। यहां मैं प्रतिशत के लिए सेटर विधि प्रदान नहीं करता हूं, इसलिए उपयोगकर्ता गेटर विधि द्वारा केवल प्रतिशत मान प्राप्त/पढ़ सकता है।

इससे अमूर्तता में सुरक्षा की ओर अग्रसर होता है जो कक्षा चर के लिए केवल सीमित (केवल पढ़ने के लिए) पहुंच प्रदान करता है।