जबकि मैं मानता हूं कि आप कम से कम विशेषाधिकार के साथ शुरू कर सकते हैं, और आवश्यकता होने पर चीजों को दृश्यता में ले जा सकते हैं, यह केवल इसलिए है क्योंकि यह उचित ऑब्जेक्ट उन्मुख डिजाइन का उत्पादन करता है, इस बारे में बहुत मुश्किल सोचने के बिना कि कक्षा सदस्य क्या है असली व्यापार समारोह जो खुलासा किया जाना चाहिए।
आपको ऑब्जेक्ट के भीतर यथासंभव अधिक जटिलता को समाहित और छिपाना चाहिए ताकि बाह्य इंटरफ़ेस जितना संभव हो उतना कम से कम हो। इसे पूरा करने का एक तरीका यह है कि आपको केवल वांछित गुणों को जोड़ना या उजागर करना है।
यदि आपको कक्षा के किसी विशेष सदस्य को बाहरी पहुंच की आवश्यकता नहीं है, तो शायद यह केवल एक कार्यान्वयन कलाकृति है, और कक्षा के वास्तविक व्यावसायिक उपयोग में फिट नहीं है। इसलिए जटिलता को छुपाया जाना चाहिए।
इस मामले में, क्योंकि टीबीआर टीएफयू से विरासत में आता है, संरक्षित वैध दृश्यता स्तर है, क्योंकि यह विरासत कक्षाओं के लिए आरक्षित है। इसके अलावा, क्योंकि टीबीआर को टीएफयू से विरासत में मिला है, शायद आप सोच रहे हैं कि इसमें टीएफयू के आंतरिक कार्यकलापों के लिए कुछ अतिरिक्त विशेषाधिकार होना चाहिए क्योंकि आखिरकार, इसके बाल वर्ग। हमें अन्य कक्षाओं के समान पहुंच के लिए टीबीएआर को क्यों पहुंचाया जाना चाहिए?
उत्तर इस बात पर निर्भर करता है कि क्या फ्लिस्ट टीएफयू का वास्तविक वर्ग सदस्य है, क्योंकि हम मानते हैं कि टीएफयू मॉडल क्या दर्शाता है, या यह केवल एक कार्यान्वयन विस्तार है या नहीं। इसके अलावा, पहुंच का स्तर क्या आवश्यक है? क्या हम इसे आसानी से एक्सेस कर रहे हैं, या क्या हम कार्यान्वयन बदल रहे हैं?
मुझे लगता है कि आपको फ्लिस्ट तक पहुंच की आवश्यकता नहीं है, और आप कार्यान्वयन को नहीं बदल रहे हैं, इस मामले में, भले ही दोनों वर्ग एक ही इकाई में हों, फिर भी मैं संरक्षित पर फ्लिस्ट प्राइवेट कर दूंगा ।
यदि आप केवल उसी इकाई के भीतर वंश वर्गों से कक्षा के सदस्य तक पहुंच रहे थे, तो भी मैं इसे निजी रखूंगा।
हालांकि, अगर फ्लिस्ट कुछ ऐसा था जो आपको टीबार में ओवरराइड करने की आवश्यकता है (शायद नहीं, क्योंकि यह कोई विधि नहीं है), या कुछ ऐसी चीज के रूप में डिज़ाइन की गई थी जो वंचित वर्गों को चाहिए या ओवरराइड करें, चाहे वह एक ही इकाई में हो या नहीं , तो आप इसे संरक्षित करना चाहते हैं।
यदि आपको उसी यूनिट के बाहर वंश वर्गों से फ्लिस्ट तक पहुंचने की आवश्यकता होती है तो आपको संरक्षित करने की दृश्यता भी बढ़ाना होगा।
यह कुछ हद तक संबंधित है http://stackoverflow.com/questions/8281582/using-properties-instead-of-fields-in-class-methods-of-the-same-unit-is-a-bad- पीआर, लेकिन अधिक विशिष्ट। –
* अनगिनत बार * मैंने कुछ ऐसा मारा है जो मेरे काम को कम करेगा अगर यह चीज़ निजी नहीं थी। मेरा मानना है कि कई अन्य लोगों ने भी ऐसा किया है क्योंकि मैंने डेवलपर्स को देखा है जो पूरी तरह से अनदेखा * निजी * और इस्तेमाल * सुरक्षित * सख्त दायरे के रूप में अनदेखा करते हैं। +1 –
@Sertac यह आमतौर पर एक समस्या है जब आपके पास अन्य कोड पर नियंत्रण नहीं होता है। जब आप सभी कोड के पूर्ण नियंत्रण में होते हैं तो आप 'निजी' या यहां तक कि 'सख्त निजी' का उपयोग कर सकते हैं और जब यह बहुत ही सीमित हो जाता है तो आप आवश्यकतानुसार प्रतिबंधों को आराम कर सकते हैं। –