2013-06-04 5 views
7

मैंने अभी प्रभावी जावा में पढ़ा है कि equals() विधि का पांचवां सिद्धांत यह है कि सभी ऑब्जेक्ट null के लिए असमान होना चाहिए। पुस्तक है कि कुछ प्रोग्रामर द्वारा लिखित कक्षाएं इस से बचाव में कहने के लिए null के लिए एक स्पष्ट परीक्षण का उपयोग कर पर चला जाता है:गैर-शून्यता आवश्यकता या सिद्धांत

public boolean equals(Object o){ 
    if (o == null) 
     return false; 
    ... 
} 

प्रभावी जावा के अनुसार, ऊपर नहीं अशक्त परीक्षण अनावश्यक है। हालांकि, मेरा सवाल यह है कि, इस गैर-शून्यता आवश्यकता के लिए इतने सारे प्रोग्रामर परीक्षण क्यों करते हैं?

+3

आप भरोसा नहीं कर सकते कि कोई भी कभी भी शून्य वस्तु में नहीं भेजेगा ... – vikingsteve

उत्तर

8

आप क्या कर सकते हैं कि एक instanceof परीक्षण के साथ:

public boolean equals(Object o){ 
    if (!(o instanceof MyObject)) 
     return false; 
    ... 
} 

null कुछ भी उदाहरण नहीं है, इसलिए इस काम करता है।

+0

निश्चित रूप से बेहतर उत्तर +1 – stinepike

+1

अब यह अच्छा है। इतना स्पष्ट है कि मुझे इस बारे में कभी पता नहीं था। +1, अगर मैं कर सकता तो मैं +2 होगा। – Fildor

+0

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

2
Object firstObject = null; 
secondObject.equals(firstObject); 

आप इसे कैसे रोक सकते हैं ?? यदि आप इसका उपयोग करने से पहले शून्य की जांच नहीं करते हैं तो यह क्रैश हो जाएगा। मैं तुम्हें भी निम्न

 if (other == null || other.getClass() != this.getClass()) { 
      return false; 
     } 
+2

असल में, आपको इसके लिए परीक्षण करने की आवश्यकता नहीं है। हम उदाहरण का उपयोग कर सकते हैं क्योंकि प्रभावी जावा में अनुशंसित विधि है। – blackpanther

+0

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

0

एक NullPointerException जब equals() कहा जाता है को रोकने के लिए की तरह वर्ग प्रकार की जांच करने की आवश्यकता होगी लगता है।

0

संभावित कारणों की जांच करने के:

पुरानी आदतों अन्य भाषाओं

से

सिद्धांत आप

पुस्तकालयों जो नल पॉइंटर अपवाद फेंक कर सकते हैं (उल्लेख से परिचित नहीं किया जा रहा है आपको लगता है कि गारंटी नहीं दे सकते किसी और कुछ बेवकूफ नहीं किया है!)

यदि आपके पास कुछ नेस्टेड कमांड हैं जिन्हें केवल आपके ऑब्जेक्ट के गैर-शून्य उदाहरण के लिए मूल्यांकन करने की आवश्यकता है तो आप

01 को बाईपास करना चाहेंगे
0

उद्योग में अनावश्यक चेक या नुकसान से बचने के लिए उद्योग में सुझाए गए कई अभ्यास हैं, लेकिन तथ्य यह है कि गलतियां हो सकती हैं या ऐसी परिस्थितियां हो सकती हैं जो किसी तीसरे पक्ष के सिस्टम से आने वाले डेटा की तरह नियंत्रण नहीं कर सकती हैं, जिसमें मूल्य है, जिसमें कोई सिस्टम है उम्मीद है कि चेक की आवश्यकता है। दुनिया सही नहीं है !!

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