डिफ़ॉल्ट पहुँच निजी पहुँच संशोधक को प्रस्तुत नहीं करता है।
उस पर भाषा डिजाइनरों की स्थिति आधिकारिक ट्यूटोरियल में परिलक्षित होती है - एक कक्षा के सदस्यों तक पहुंच को नियंत्रित करना और यह बहुत स्पष्ट है (आपकी सुविधा के लिए, बोली में प्रासंगिक कथन बोल्ड किया गया है ):
एक्सेस स्तर चुनने पर सुझाव:
यदि अन्य प्रोग्रामर आपकी कक्षा का उपयोग करते हैं, तो आप यह सुनिश्चित करना चाहते हैं कि दुरुपयोग से त्रुटियां नहीं हो सकती हैं। प्रवेश स्तर आपको ऐसा करने में मदद कर सकता है।
- सबसे अधिक प्रतिबंधात्मक पहुंच स्तर का उपयोग करें जो किसी विशेष सदस्य के लिए समझ में आता है। जब तक आपके पास कोई अच्छा कारण न हो, निजी का उपयोग करें।
- स्थिरांक को छोड़कर सार्वजनिक क्षेत्रों से बचें। (ट्यूटोरियल में कई उदाहरण सार्वजनिक क्षेत्रों का उपयोग करते हैं। यह कुछ बिंदुओं को संक्षिप्त रूप से चित्रित करने में मदद कर सकता है, लेकिन उत्पादन कोड के लिए अनुशंसित नहीं है।) सार्वजनिक क्षेत्र आपको एक विशेष कार्यान्वयन से जोड़ते हैं और आपके कोड को बदलने में आपके लचीलेपन को सीमित करते हैं।
पूरी तरह से निजी संशोधक को छोड़ने के औचित्य के रूप में परीक्षण के लिए आपकी अपील गलत है, उदाहरण के लिए टीडीडी में नए द्वारा दिए गए उदाहरणों से। क्या मुझे अब निजी तरीकों से बचना चाहिए?
बेशक आपके पास निजी तरीके हो सकते हैं, और निश्चित रूप से आप उनका परीक्षण कर सकते हैं।
या तो वहाँ है कुछ रास्ता चलाने के लिए निजी विधि प्राप्त करने के लिए, इस स्थिति में आप इसे उस तरह से परीक्षण कर सकते हैं, या वहाँ कोई चलाने के लिए निजी प्राप्त करने के लिए जिस तरह से, जिस स्थिति में: क्यों हो तुम यह परीक्षण करने के लिए कोशिश कर रहे हैं, बस धिक्कार है हटाओ ...
पैकेज स्तर पहुंच के उद्देश्य और उपयोग पर भाषा डिजाइनरों की स्थिति को एक अन्य आधिकारिक ट्यूटोरियल में समझाया गया है, पैकेज बनाना और उपयोग करना और इसमें निजी संशोधक छोड़ने के विचार के साथ सामान्य रूप से कुछ भी नहीं है (आपकी सुविधा के लिए, बोली में बोल्ड किए गए प्रासंगिक विवरण ) :
आपको निम्न सहित कई कारणों से इन कक्षाओं और इंटरफ़ेस को एक पैकेज में बंडल करना चाहिए:
- आप और अन्य प्रोग्रामर आसानी से निर्धारित कर सकते हैं कि ये प्रकार संबंधित हैं ...
- आप पैकेज के भीतर प्रकारों को एक दूसरे के लिए अप्रतिबंधित पहुंच रखने की अनुमति दे सकते हैं, फिर भी पैकेज के बाहर के प्रकारों के लिए पहुंच को प्रतिबंधित कर सकते हैं ...
<शेख़ी "मुझे लगता है कि मैंने पर्याप्त स्वर सुना है। लगता है कि यह जोर से और स्पष्ट रूप से कहने का समय है ...">
यूनिट परीक्षण के लिए निजी तरीके फायदेमंद होते हैं।
नीचे ध्यान दें कि आप कोड कवरेज से परिचित हैं । यदि नहीं, तो सीखने के लिए समय निकालें, क्योंकि यह यूनिट परीक्षण में रुचि रखने वालों और परीक्षण में बिल्कुल उपयोगी है।
सब ठीक है, इसलिए मैंने उस निजी पद्धति और इकाई परीक्षणों, और कवरेज विश्लेषण से मुझे बताया है कि एक अंतर है, मेरी निजी पद्धति परीक्षणों द्वारा कवर नहीं की गई है। अभी व...
इसे निजी रखने से मुझे क्या लाभ होगा
चूंकि विधि निजी है, इसलिए आगे बढ़ने का एकमात्र तरीका यह जानने के लिए कोड का अध्ययन करना है कि इसका उपयोग गैर-निजी एपीआई के माध्यम से कैसे किया जाता है। आमतौर पर, इस तरह के एक अध्ययन से पता चलता है कि अंतर का कारण यह है कि परीक्षणों में विशेष उपयोग परिदृश्य गायब है।
void nonPrivateMethod(boolean condition) {
if (condition) {
privateMethod();
}
// other code...
}
// unit tests don't invoke nonPrivateMethod(true)
// => privateMethod isn't covered.
पूर्णता के लिए, ऐसे कवरेज अंतराल के लिए अन्य (कम लगातार) कारणों से विनिर्देश / डिजाइन में कीड़े हो सकते हैं। मैं यहाँ इन चीजों को सरल रखने के लिए गहराई से गोता नहीं लगाऊँगा; यह कहने के लिए पर्याप्त है कि यदि आप "केवल परीक्षण योग्य बनाने के लिए पहुँच सीमा" को कमज़ोर करते हैं, तो आपको यह जानने का मौका मिलेगा कि ये बग बिल्कुल मौजूद हैं।
अंतर को ठीक करने के लिए, मैं लापता परिदृश्य के लिए एक इकाई परीक्षण जोड़ता हूं, कवरेज विश्लेषण दोहराता हूं और सत्यापित करता हूं कि अंतर समाप्त हो गया है। मेरे पास अब क्या है? मुझे गैर-निजी एपीआई के विशिष्ट उपयोग के लिए नई इकाई परीक्षा मिली है।
नया परीक्षण यह सुनिश्चित करता है कि इस उपयोग के लिए अपेक्षित व्यवहार बिना सूचना के नहीं बदलेगा क्योंकि यदि यह बदल जाता है, तो परीक्षण विफल हो जाएगा।
एक बाहरी पाठक इस परीक्षण को देख सकता है और सीख सकता है कि इसका उपयोग और व्यवहार कैसे करना है (यहां, बाहर के पाठक में मेरा भविष्य स्वयं शामिल है, क्योंकि मैं कोड को एक या दो महीने बाद भूल जाता हूं, जब मैं इसके साथ किया जाता हूं)।
नए परीक्षण पुनर्रचना के सहिष्णु (मैं निजी तरीकों refactor? आप शर्त लगा सकता!) जो कुछ भी मैं करने के लिए क्या है privateMethod, मैं हमेशा परीक्षण करना चाहते हैं nonPrivateMethod(true)। कोई फर्क नहीं पड़ता कि मैं क्या करता हूं privateMethod, परीक्षण को संशोधित करने की कोई आवश्यकता नहीं होगी क्योंकि विधि सीधे लागू नहीं होती है।
बुरा नहीं? बिलकुल।
मैं पहुंच सीमा को कमजोर करने से क्या ढीला कर सकता हूं
अब कल्पना करें कि ऊपर के बजाय, मैं बस पहुंच सीमा को कमजोर करता हूं। मैं उस कोड के अध्ययन को छोड़ देता हूं जो विधि का उपयोग करता है और सीधे उस परीक्षण के साथ आगे बढ़ता है जो मेरा आह्वान करता है exPrivateMethod। महान? नहीं!
क्या मैं ऊपर उल्लिखित गैर-निजी एपीआई के विशिष्ट उपयोग के लिए एक परीक्षण प्राप्त कर सकता हूं? नहीं: nonPrivateMethod(true)पहले कोई टेस्ट नहीं था , और अब ऐसा कोई टेस्ट नहीं है।
क्या बाहर के पाठकों को कक्षा के बेहतर उपयोग को समझने का मौका मिलता है? नहीं। "- अरे यहाँ पर परीक्षण की गई विधि का क्या उद्देश्य है? - इसे भूल जाओ, यह आंतरिक उपयोग के लिए कड़ाई से है। - उफ़।"
क्या यह रिफलेक्टिंग के प्रति सहिष्णु है? कोई रास्ता नहीं: मैं जो भी बदलूंगा exPrivateMethod, वह परीक्षण को तोड़ देगा। नाम बदलें, किसी अन्य विधि में विलय करें, तर्क बदलें और परीक्षण बस संकलन बंद कर देगा। सरदर्द? बिलकुल!
संक्षेप में, निजी विधि के साथ चिपके हुए मुझे इकाई परीक्षण में एक उपयोगी, विश्वसनीय वृद्धि लाता है। इसके विपरीत, "परीक्षण के लिए" सीमाओं को कमजोर करना "केवल मुझे एक अस्पष्ट, परीक्षण कोड के टुकड़े को समझने के लिए कठिन देता है, जो कि किसी भी मामूली रिफैक्टरिंग द्वारा टूटने के स्थायी जोखिम के अतिरिक्त है; स्पष्ट रूप से मुझे जो मिलता है वह तकनीकी ऋण की तरह संदिग्ध दिखता है ।
</ शेख़ी>