2012-06-17 15 views
29

संभव डुप्लिकेट:
Why use getters and setters?लाभ और तरीकों बनाम सार्वजनिक चर मिल

कोई लाभ अपनी कक्षा में निजी चर का उपयोग करने के तरीकों बनाने के बजाय चर को सार्वजनिक करने के लिए है ?

उदाहरण के लिए दूसरा मामला पहले से बेहतर है?

//Case 1 
public class Shoe{ 
    public int size; 
} 

//Case 2 
public class Shoe{ 
    private int size; 
    public int getSize(){ 
     return size; 
    } 

    public void setSize(int sz){ 
     size = sz; 
    } 

} 
+0

संभावित डुप्लिकेट [गेटर्स और सेटर्स का उपयोग क्यों करें?] (Http://stackoverflow.com/questions/1568091/why-use-getters-and-setters) और [स्वत: कार्यान्वित गेटर्स और सेटर्स बनाम सार्वजनिक क्षेत्रों] (http://stackoverflow.com/questions/111461) –

उत्तर

59

क्या मैं इतने पर किसी दिन देखा है, जवाब के रूप में (@ ChssPly76 द्वारा लिखित) क्यों getters और setters

उपयोग करने के लिए क्योंकि अब से 2 सप्ताह (महीने, साल) जब आप उस एहसास अपने सेटर अधिक करने के लिए की तुलना में सिर्फ मान सेट की जरूरत है, तो आप भी एहसास होगा कि संपत्ति 238 अन्य वर्गों में सीधे इस्तेमाल किया गया है :-)

भी बहुत कुछ लाभ हैं:

  1. getters और सेटर उन में मान्यता हो सकता है, खेतों वांछित वर्ग के उपवर्ग प्राप्त कर सकते हैं आप मनुष्य का उपयोग नहीं कर
  2. कर सकते हैं।
  3. getters और setters बहुरूपी हैं, खेतों डिबगिंग बहुत सरल हो सकता है, क्योंकि ब्रेकपाइंट एक विधि है जो दिए गए क्षेत्र के कई के पास नहीं संदर्भ के अंदर रखा जा सकता है नहीं
  4. हैं।
  5. वे कर सकते हैं छिपाने कार्यान्वयन में परिवर्तन:

से पहले:

private boolean alive = true; 

public boolean isAlive() { return alive; } 
public void setAlive(boolean alive) { this.alive = alive; } 

के बाद:

private int hp; // change! 

public boolean isAlive() { return hp > 0; } // old signature 
//method looks the same, no change in client code 
public void setAlive(boolean alive) { this.hp = alive ? 100 : 0; } 

संपादित: एक अतिरिक्त नई advange जब आप ग्रहण का उपयोग कर रहे हैं - आप क्षेत्र पर घड़ी बिंदु बना सकते हैं, लेकिन यदि आपके पास सेटटर है तो आपको चाहिए बस एक ब्रेकपॉइंट, और ... ब्रेकपॉइंट्स (उदा। सेटर विधि में) सशर्त हो सकता है, घड़ी (क्षेत्र पर) नहीं हो सकता है। इसलिए यदि आप अपने डीबगर को केवल x=10 पर रोकना चाहते हैं तो आप इसे केवल सेटटर के अंदर ब्रेकपॉइंट के साथ कर सकते हैं।

+0

गेटर्स और अच्छे हिस्सों को सेट करता है (http://pawel-michalski-javnie.blogspot.de/2012 /04/gettery-settery-enkapsulacja-czy.html) बिल्कुल मजाकिया नहीं है ... इसे अंग्रेजी शीर्षक क्यों दें और कुछ अजीब भाषा के साथ आगे बढ़ें ... –

+1

@MatthisKohli क्षमा करें, आप सही हैं। मैंने उस लिंक को हटा दिया। – dantuch

4
  1. कुछ पुस्तकालयों को "जावा बीन मानक" को पूरा करने के लिए इसकी आवश्यकता होती है।
  2. एक सेटर/गेटर एक इंटरफ़ेस में हो सकता है, एक संपत्ति इंटरफेस में नहीं हो सकती है
  3. सेटर्स/गेटर्स को आसानी से अवरोही कक्षाओं में ओवरराइड किया जा सकता है।
  4. setters/सार दूर ही टिककर खेल जानकारी एक मूल्य मांग या एक संपत्ति
6

सार्वजनिक चर का उपयोग करना चर करने के लिए गलत मान सेट पैदा कर सकता है के लिए सिर्फ एक्सेसर पर गणना की जाती है कि क्या के रूप में इनपुट मूल्य नहीं जांचा जा सकता ।

जैसे:

public class A{ 

    public int x; // Value can be directly assigned to x without checking. 

    } 

सेटर का उपयोग इनपुट जाँच के साथ चर सेट करने के लिए इस्तेमाल किया जा सकता। उदाहरण रखते हुए निजी varibale, और गेटर और सेटर सार्वजनिक Encapsulation गेटर का एक रूप है और सेटर भी जावा बीन्स मानक के साथ संगत है,

गेटर और सेटर भी को लागू करने बहुरूपता अवधारणा

में मदद करता है

जैसे:

public class A{ 

    private int x;  // 


     public void setX(int x){ 

     if (x>0){      // Checking of Value 
     this.x = x; 
     } 

     else{ 

      System.out.println("Input invalid"); 

     } 
    } 

     public int getX(){ 

      return this.x; 
     } 

बहुरूपी उदाहरण: हम assig कर सकते हैं एन ऑब्जेक्ट रिफर्नेंस उप-प्रकार के वेरिएबल को कॉलिंग विधि से ऑब्जेक्ट रिफर्नेंस पर कॉल किया गया है जिसे कॉलेड विधि के सुपर क्लास पैरामीटर का वैरिएबल किया जा सकता है।

public class Animal{ 

     public void setSound(Animal a) { 

      if (a instanceof Dog) {   // Checking animal type 

       System.out.println("Bark"); 

      } 

     else if (a instanceof Cat) {  // Checking animal type 

       System.out.println("Meowww"); 

      } 
     } 
     } 
0

चीजों को देखने का कुछ हद तक पीछे का तरीका।

क्या ऐसी कोई परिस्थितियां हैं जहां सदस्य वर्ग को सार्वजनिक बनाकर अपनी कक्षा के आंतरिक कार्यों को बेनकाब करना बेहतर होता है, इसलिए इसका कोई भी उपभोक्ता उन चीजों को कर सकता है जो डिजाइनर ने कभी नहीं प्राप्त किया है, जिससे विफलता का एक दावत और कॉर्नुकोपिया दुर्घटनाओं?

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

ओओ, encapsulation के कॉर्नरस्टोन सिद्धांत। एक सार्वजनिक सदस्य चर मूल रूप से एक उपसर्ग के साथ वैश्विक चर है ...

+4

गेटर्स और सेटर्स का उपयोग न करने के अच्छे कारण हैं - वे कोड को अव्यवस्थित करते हैं, जिससे इसे पढ़ने में कठिनाई होती है, और वे DRY सिद्धांत का उल्लंघन करते हैं। वास्तव में, गुणों वाली भाषाओं में, केवल चीजों को सार्वजनिक करना आम बात है (क्योंकि यह वास्तव में आवश्यक होने पर बाद में गुणों में पुन: सक्रिय किया जा सकता है)। – Antimony

+0

@ एंटीमोनी। बहस के लिए जगह नहीं है, लेकिन मैं सहमत नहीं हो सकता, थोड़ा सा भी नहीं। मैंने देखा है कि बहुत से उदाहरण थे कि 'शर्मिंदगी शॉर्टकट' ने एक संपत्ति के लिए केवल पुन: काम करने की तुलना में अधिक काम किया है। बहुत, बहुत कुछ। –

संबंधित मुद्दे