ओओपी में, कक्षा के अंदर "यह" का उपयोग करने के संबंध में सबसे अच्छा अभ्यास क्या है?

Question

कुछ मैंने हमेशा सोचा है; एक वर्ग में जहां आप किसी सदस्य को 'यह [NAME]' या बस [NAME] का उपयोग कर संदर्भित कर सकते हैं, जिसे प्राथमिकता दी जाती है?

जावा में

उदाहरण के लिए:

public class foo { 
    public int bars = 0; 
    private void incrementBars(){ 
     bars++; 
    } 
} 

और

public class foo { 
    public int bars = 0; 
    private void incrementBars(){ 
     this.bars++; 
    } 
} 

'को' एक ही प्रभाव है।

मामलों में जहां मैं कक्षा foo के कई उदाहरण का दृष्टांत में, मैं चाहते, अब तक, कुछ ऐसा कार्य करें:

for (foo f : listOfFoos){ 
    f.incrementBars(); 
} 

और यह अभी भी काम करने के लिए लगता है।

क्या यह तकनीकी रूप से संदिग्ध है, और यदि ऐसा कोई पसंदीदा तरीका है?

Answer 1

variable shadowing के मामले में this का उपयोग करें।

class MyClass{ 
     int i;//1 
     public void myMethod(){ 
      i = 10;//referring to 1  
     } 

     public void myMethod(int i){//2 
      i = 10;//referring to 2 
      this.i = 10 //refering to 1  
     }  
    } 

भी कुछ समय this आप this का उपयोग सुनिश्चित करने और संवाद है कि आप एक क्षेत्र साथ काम कर रहे करने के लिए हमारे अंग्रेजी मानसिकता

Answer 2

की वजह कोड अधिक पठनीय कर देगा।

यह आप की तरह

public void setX(int x) { 
    this.x = x; 
} 

जो बहुत लधु है एक सेटर लिखने के लिए अनुमति देता है।

Answer 3

आपको केवल this. की आवश्यकता होती है जब वर्तमान दायरे में एक ही नाम का चर होता है। मैं सभी वर्ग चर के लिए _variable के सम्मेलन का उपयोग करना पसंद करता हूं। इस तरह मुझे कभी भी this. का उपयोग नहीं करना पड़ेगा और कभी भी एक क्लास वैरिएबल को स्पर्श नहीं करेगा क्योंकि यह स्थानीय रूप से स्कॉप्ड वैरिएबल था।

Answer 4

कोई अस्पष्टता नहीं है। यदि वहां थे, तो का उपयोग करने के लिए में होगा।

कुछ लोग स्पष्टता के लिए this की सलाह देते हैं। जब इसकी आवश्यकता नहीं होती है, तो अन्य इसके खिलाफ अनुशंसा करते हैं, क्योंकि यह "शोर" पेश करता है। कुछ आधुनिक आईडीई या संपादक स्पष्टता के लिए फ़ील्ड से अलग-अलग रंगों (उदाहरण के लिए) तर्कों पर हाइलाइटिंग सिंटैक्स का उपयोग करने में सक्षम हो सकते हैं।

व्यक्तिगत रूप से मैं this से बचता हूं जब मैं @unholysampler's underscore convention का उपयोग कर सकता हूं। अपने सहकर्मियों के साथ कुछ पर सहमत हों और इसे अपने कोडिंग मानकों में डाल दें।

Answer 5

class Test 
{ 
    private int value; 

    public Test(int value) 
    { 
    // This is wrong 
    // value = value 

    // This is right 
    this.value = value; 
    } 
} 

उपयोग "इस" जब वे एक स्थानीय चर द्वारा छुपाए गए हैं सदस्य चर का उपयोग करने की। के बाद से "इस" मौजूदा वस्तु को केवल एक संदर्भ है, कहां कर सकते हैं:

doSomething(this); 

ये मूलतः केवल तरीकों से आप कभी भी इस का उपयोग करने की आवश्यकता होगी रहे हैं।

Answer 6

यह तकनीकी रूप से अस्पष्ट है जहां आप चरम छायांकन कर रहे हैं (जो जिगर ने अपने उत्तर में बताया)।

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

इसके साथ, मैं इस क्षेत्र का उपयोग करना पसंद करता हूं ताकि ऑब्जेक्ट में मौजूद सभी फ़ील्ड को संदर्भित किया जा सके, क्योंकि केवल इसलिए कि मुझे पता है कि हर अब और फिर मैं अपने सामान्य आईडीई के बाहर कोड पढ़ूंगा। यह मामूली रूप से अधिक verbose है, लेकिन यह एक व्यापार है कि मुझे कोई फर्क नहीं पड़ता।

Answer 7

आपके प्रश्न में पहले दो नमूने बिल्कुल वही चीज़ हैं।

public class Test { 
    private int a; 

    public void noShadow() { 
     System.out.println(a); // attribute 
    } 

    public void shadow(int a) { 
     System.out.println(a); // parameter 
     System.out.println(this.a); // attribute 
    } 
} 

अब मुझे नहीं लगता कि एक निरपेक्ष सबसे अच्छा अभ्यास नहीं है, आधुनिक IDEs उन्नत वाक्य रचना हाइलाइटिंग प्रदान विशेष रूप से के रूप में है: केवल जहां this अनिवार्य है जब एक विशेषता एक स्थानीय चर द्वारा आच्छादित है है। कुछ _, m_ इत्यादि के साथ विशेषता को उपसर्ग करना पसंद करते हैं और this का उपयोग नहीं करते हैं। कुछ this का उपयोग करना अनिवार्य है और विशेषताओं पर कोई नामकरण नियम नहीं जोड़ना पसंद करते हैं। आप जो करने जा रहे हैं वह मौजूदा कोड या मौजूदा कोडिंग मानकों के आधार पर काफी हद तक है। मैं कुछ भी सुनिश्चित नहीं करता हूं कि परियोजना पर काम करने वाले सभी लोगों के लिए कोडिंग मानकों का समान होगा।