निजी बनाम संरक्षित - दृश्यता अच्छा अभ्यास चिंता [बंद]

Question

मैं खोज कर रहा हूं और मैं सिद्धांत को जानता हूं।

• सार्वजनिक - कोई भी वर्ग / कार्य विधि / संपत्ति तक पहुंच सकता है।
• संरक्षित - केवल इस वर्ग और किसी भी उपवर्ग विधि / संपत्ति का उपयोग कर सकते हैं।
• निजी - केवल यह वर्ग विधि / संपत्ति तक पहुंच सकता है। यह भी विरासत में नहीं मिलेगा।

यह सब ठीक है और ठीक है, सवाल यह है कि उनके बीच व्यावहारिक अंतर क्या है? आप कब इस्तेमाल करेंगे privateऔर कब इस्तेमाल करेंगे protected? क्या इस पर एक मानक या स्वीकार्य अच्छा अभ्यास है?

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

(ध्यान दें कि यह प्रश्न मेरे लिए है, लेकिन भविष्य के संदर्भ के लिए भी क्योंकि मैंने इस तरह का एक प्रश्न नहीं देखा है)।

Comments

फर्क पड़ता है क्या? OOP समर्थन वाली किसी भी भाषा में यह चिंता है। मैं PHP में प्रोग्राम करने के लिए होता हूं, लेकिन मुझे लगता है कि सवाल किसी भी OOP सहायक भाषा के लिए लागू होता है।

— मदारा का भूत

ठीक है पर्याप्त, बस अगर आप टैग करना भूल गए थे तो सोच रहे थे। अब मुझे oop टैग दिखाई देता है।

— पॉल बेलोरा

मुझे कक्षा की प्रत्येक संपत्ति के लिए दृश्यता (निजी / सार्वजनिक / संरक्षित) सेट करनी होगी? या उनमें से केवल कुछ को दृश्यता प्रकार की आवश्यकता है? यदि हाँ, तो यह कैसे तय किया जाए कि किस संपत्ति के लिए कक्षा के शीर्ष पर दृश्यता सेट होनी चाहिए?

— 184 बजे user4271704

ऑफहैंड, संरक्षित और निजी के बीच का अंतर स्पष्ट लगता है। यदि उप-विधि विधि / चर का उपयोग करेगी, तो संरक्षित का उपयोग करें, अन्यथा निजी का उपयोग करें। विशेष रूप से, अगर उपवर्गों को माता-पिता में एक बहुत ही समान निजी चर को फिर से परिभाषित करना होगा, तो इसे संरक्षित करें।

— iPherian

internalसी # भाषा में एक और एक्सेस स्पेसियर है जो एक भौतिक विधानसभा के भीतर एक वर्ग या उसके सदस्यों के एक्सेस स्तर को प्रतिबंधित करता है। हालांकि, मैं इसके समर्थन या अन्य भाषाओं में समान के बारे में निश्चित नहीं हूं।

— आरबीटी

Answer 1

नहीं, आप सही रास्ते पर नहीं हैं। अंगूठे का एक अच्छा नियम है: जितना संभव हो सब कुछ निजी बनाएं। यह आपकी कक्षा को अधिक संक्षिप्त बनाता है, और आपकी कक्षा का उपयोग करके कोड को प्रभावित किए बिना कक्षा के आंतरिक को बदलने की अनुमति देता है।

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

एक वर्ग जिसे विरासत में लेने का इरादा नहीं है, उसे अंतिम (जावा में) बनाया जाना चाहिए। आप यूनिट-टेस्टिंग के लिए कुछ एक्सेस नियमों (प्राइवेट से प्रोटेक्टेड, नॉन-फाइनल तक) को आराम कर सकते हैं, लेकिन फिर उसे डॉक्यूमेंट करें, और यह स्पष्ट करें कि हालांकि यह विधि सुरक्षित है, यह ओवरराइड नहीं होना चाहिए।

Comments

यहाँ असली सवाल, privateबनाम के बारे में है protectedजब मैं चाहता हूं कि एक संपत्ति विरासत में मिले, और कब नहीं? मैं वास्तव में यह नहीं बता सकता कि क्या भविष्य में कभी-कभी कोई उपयोगकर्ता मेरी कक्षा लेना चाहता है और इसे आगे बढ़ा सकता है ...

— मदारा का घोस्ट

खैर, सवाल यह नहीं है कि उपयोगकर्ता क्या ओवरराइड करना चाहता है, सवाल यह है कि आप ओवरराइड होने देना चाहते हैं । आमतौर पर यह पक्षों को बदलने और सोचने की कोशिश करने में मदद करता है: अगर मैंने उस वर्ग का उपयोग किया और एक उपवर्ग बनाया, तो मैं क्या ओवरराइड करने में सक्षम होना चाहूंगा? कभी-कभी अन्य उपयोगकर्ता अभी भी चीजों को याद करेंगे ...

— Thorsten Dittmar

संरक्षित क्षेत्र विरासत में खराब प्रथा हैं! । कृपया इससे सावधान रहें। यहाँ क्यों है

— RBT

निजी क्षेत्र विरासत में व्यवहार में खराब हैं!। (अतिशयोक्ति पर) कृपया मेरा उत्तर पढ़ें।

— लैरी

विशिष्ट नियंत्रण-फ्रीक राय।

— ब्रूनो डेथिलियर्स

Answer 2

मुझे यह कहकर प्रस्तावना दें कि मैं मुख्य रूप से यहां विधि अभिगम के बारे में बात कर रहा हूं, और कुछ हद तक, अंतिम रूप से अंकन करना, न कि सदस्य अभिगम।

पुराना ज्ञान

"इसे निजी चिह्नित करें जब तक कि आपके पास एक अच्छा कारण न हो"

उन दिनों में समझ में आया जब इसे लिखा गया था, इससे पहले कि खुला स्रोत डेवलपर लाइब्रेरी स्पेस और VCS / निर्भरता mgmt पर हावी हो। गितुब, मावेन आदि के लिए हाइपर सहयोगी धन्यवाद बन गया, फिर उस रास्ते (एस) को बाधित करने के लिए भी पैसा था, जिसमें एक पुस्तकालय का उपयोग किया जा सकता था। मैंने अपने करियर के पहले 8 या 9 साल शायद इस "सर्वश्रेष्ठ अभ्यास" का सख्ती से पालन करने में बिताए।

आज, मैं इसे बुरी सलाह मानता हूं। कभी-कभी एक विधि निजी, या एक वर्ग के फाइनल को चिह्नित करने के लिए एक उचित तर्क है, लेकिन यह बहुत दुर्लभ है, और तब भी यह शायद कुछ भी सुधार नहीं कर रहा है।

क्या आपने कभी:

• एक पुस्तकालय आदि से निराश, आश्चर्यचकित या आहत हुए, जिसमें बग था जो विरासत और कोड की कुछ पंक्तियों के साथ तय किया जा सकता था, लेकिन निजी / अंतिम तरीकों और कक्षाओं के कारण एक आधिकारिक पैच के लिए इंतजार करने के लिए मजबूर किया गया था जो कभी नहीं आ सकता है? मेरे पास है।
• लेखकों द्वारा कल्पना की तुलना में थोड़ा अलग उपयोग के मामले में एक पुस्तकालय का उपयोग करना चाहते थे, लेकिन निजी / अंतिम तरीकों और कक्षाओं के कारण ऐसा करने में असमर्थ थे? मेरे पास है।
• एक पुस्तकालय आदि से निराश, आश्चर्यचकित या आहत हो गया, जो इसकी अत्यधिकता में पारंगत था? मेरे पास नही है।

ये तीन सबसे बड़ी युक्तियां हैं जिन्हें मैंने डिफ़ॉल्ट रूप से निजी तरीकों को चिह्नित करने के लिए सुना है:

युक्तिकरण # 1: यह असुरक्षित है और किसी विशिष्ट विधि को ओवरराइड करने का कोई कारण नहीं है

मैं इस बात की गिनती नहीं कर सकता कि मैं इस बारे में गलत हूं कि मेरे द्वारा लिखे गए किसी विशिष्ट तरीके को ओवरराइड करने की आवश्यकता होगी या नहीं। कई लोकप्रिय ओपन सोर्स लिबास पर काम करने के बाद, मैंने चीजों को निजी तौर पर चिह्नित करने की सही लागत को सीखा। यह अक्सर अप्रत्याशित समस्याओं या मामलों का उपयोग करने के लिए एकमात्र व्यावहारिक समाधान को समाप्त करता है। इसके विपरीत, मैंने कभी भी 16+ वर्षों में व्यावसायिक विकास नहीं किया है जो एपीआई सुरक्षा से संबंधित कारणों के लिए निजी के बजाय संरक्षित विधि को चिह्नित करता है। जब एक डेवलपर एक वर्ग का विस्तार करने और एक विधि को ओवरराइड करने का विकल्प चुनता है, तो वे सचेत रूप से कह रहे हैं "मुझे पता है कि मैं क्या कर रहा हूं।" और उत्पादकता के लिए जो पर्याप्त होना चाहिए। अवधि। यदि यह खतरनाक है, तो इसे क्लास / मेथड Javadocs में नोट करें, बस दरवाज़ा बंद करके आँख बंद करके न करें।

डिफ़ॉल्ट रूप से संरक्षित तरीके चिह्नित करना आधुनिक एसडब्ल्यू विकास में प्रमुख मुद्दों में से एक के लिए एक शमन है: कल्पना की विफलता।

युक्तिकरण # 2: यह सार्वजनिक API / Javadocs को साफ रखता है

यह एक अधिक उचित है, और लक्षित दर्शकों पर निर्भर करता है कि यह सही काम भी हो सकता है, लेकिन यह विचार करने लायक है कि वास्तव में एपीआई "स्वच्छ" रखने की लागत क्या है: एक्स्टेंसिबिलिटी। ऊपर वर्णित कारणों के लिए, यह संभवतया डिफ़ॉल्ट रूप से संरक्षित चीजों को केवल मामले में चिह्नित करने के लिए अधिक समझ में आता है।

युक्तिकरण # 3: मेरा सॉफ्टवेयर वाणिज्यिक है और मुझे इसका उपयोग प्रतिबंधित करने की आवश्यकता है।

यह उचित भी है, लेकिन एक उपभोक्ता के रूप में मैं हर बार कम प्रतिबंधक प्रतियोगी (कोई महत्वपूर्ण गुणवत्ता अंतर मौजूद नहीं है) के साथ जाऊंगा।

नेवर से नेवर

मैं यह नहीं कह रहा हूं कि तरीकों को कभी भी निजी न रखें। मैं कह रहा हूं कि अंगूठे का बेहतर नियम है "जब तक कोई अच्छा कारण न हो, तब तक तरीकों को संरक्षित रखें"।

यह सलाह उन पुस्तकालयों या बड़े पैमाने पर परियोजनाओं पर काम करने वालों के लिए सबसे उपयुक्त है जिन्हें मॉड्यूल में तोड़ा गया है। छोटी या अधिक अखंड परियोजनाओं के लिए यह उतना मायने नहीं रखता है, जितना कि आप वैसे भी सभी कोड को नियंत्रित करते हैं और यदि आपके पास आवश्यकता होती है, तो अपने कोड के एक्सेस स्तर को बदलना आसान है। हालांकि तब भी, मैं अभी भी वही सलाह दूंगा :-)

Comments

अपने लिखे Rationalization # 1- जब मैं किसी चीज को संरक्षित करता हूं, तो मैं उसे स्पष्ट रूप से करने के लिए चुनता हूं क्योंकि मुझे लगता है कि यह व्यवहार अंतिम नहीं है और ऐसा मामला हो सकता है जहां मेरा बच्चा वर्ग इसे ओवरराइड करना चाहेगा। अगर मुझे यकीन नहीं है तो मैं इसे डिफ़ॉल्ट रूप से निजी बनाना चाहूंगा। विशेष रूप से C # जैसी भाषा में, जो डिफ़ॉल्ट रूप से गैर-आभासी रहती है, केवल संरक्षित एक्सेस स्पेसियर को जोड़ने से कोई मतलब नहीं होता है। आपको अपने इरादे को बहुत स्पष्ट करने के लिए दोनों virtualऔर protectedखोजशब्दों को जोड़ना होगा । इसके अलावा, लोग इनहेरिटेंस पर एसोसिएशन पसंद करते हैं ताकि protectedडिफ़ॉल्ट को समझना मुश्किल हो

— RBT

एक विधि को अधिक उपयोगी बनाने के लिए आवश्यक कीवर्ड का संयोजन एक भाषा विस्तार IMHO है। मैं तर्क # 1 के प्रति जो तर्क प्रस्तुत करता हूं, वह "यदि मुझे इतना यकीन नहीं है ..." के मामले में है। व्यावहारिक रूप से, यदि आप एक कारण के बारे में नहीं सोच सकते हैं कि यह खतरनाक क्यों होगा तो एक्स्टेंसिबिलिटी के लिए चयन करके अधिक प्राप्त किया जा सकता है। जब आप कहते हैं कि 'एसोसिएशन' मैं इसे कंपोजीशन का पर्याय बना रहा हूं, तो जिस स्थिति में मैं इसे मायने नहीं रखता।

— निक

मुझे याद नहीं है कि मुझे कितनी बार अंतर्निहित कक्षाओं को "क्लोन" करना पड़ा था क्योंकि मैं 1 या 2 या विधियों को ओवरराइड करना चाहता था। और जैसा आपने कहा था, उस सामाजिक प्रवृत्ति के साथ, जिसे हम पहले से कहीं अधिक कोड साझा कर रहे हैं, यह डिफ़ॉल्ट रूप से निजी की तुलना में संरक्षित के साथ जाने के लिए बहुत अधिक समझ में आता है। यानी अपने स्वयं के लॉजिक्स के लिए अधिक खुला होना चाहिए।

— शिनकौ

इस बात से सहमत। मैं सिर्फ कस्टम लाइन सीमांकक को संभालने के लिए जावा के बफ़रडर को ट्विक करना चाहता था। निजी क्षेत्रों के लिए धन्यवाद मुझे पूरी क्लास को क्लोन करने की बजाय केवल इसे विस्तार देने और रीडलाइन () को ओवरराइड करने की आवश्यकता है।

— रॉन डन

Answer 3

निजी क्षेत्रों को गाली देना बंद करो !!!

यहाँ टिप्पणियाँ निजी क्षेत्रों का उपयोग करने के लिए भारी सहायक लगती हैं। अच्छा, फिर मेरे पास कहने के लिए कुछ अलग है।

क्या निजी क्षेत्र सिद्धांत रूप में अच्छे हैं? हाँ। लेकिन यह कहते हुए कि एक सुनहरा नियम सब कुछ निजी है जब आप सुनिश्चित नहीं हैं कि निश्चित रूप से गलत है ! आप समस्या को तब तक नहीं देखेंगे जब तक आप एक में नहीं चलते। मेरी राय में, यदि आप सुनिश्चित नहीं हैं, तो आपको खेतों को संरक्षित करना चाहिए ।

दो मामले हैं जो आप एक वर्ग का विस्तार करना चाहते हैं:

• आप बेस क्लास में अतिरिक्त कार्यक्षमता जोड़ना चाहते हैं
• आप मौजूदा पैकेज के बाहर मौजूदा वर्ग को संशोधित करना चाहते हैं (कुछ पुस्तकालयों में शायद)

पहले मामले में निजी क्षेत्रों के साथ कुछ भी गलत नहीं है। यह तथ्य कि लोग निजी क्षेत्रों का दुरुपयोग कर रहे हैं, यह आपको निराश करता है जब आपको पता चलता है कि आप गंदगी को संशोधित नहीं कर सकते हैं।

एक साधारण पुस्तकालय पर विचार करें जो कारों को मॉडल करता है:

class Car {
    private screw;
    public assembleCar() {
       screw.install();
    };
    private putScrewsTogether() {
       ...
    };
}

पुस्तकालय लेखक ने सोचा: कोई कारण नहीं है कि मेरे पुस्तकालय के उपयोगकर्ताओं को assembleCar()अधिकार के कार्यान्वयन विवरण तक पहुंचने की आवश्यकता है ? चलो पेंच को निजी के रूप में चिह्नित करें।

खैर, लेखक गलत है। यदि आप assembleCar()पूरी विधि को अपने पैकेज में कॉपी किए बिना केवल विधि को संशोधित करना चाहते हैं , तो आप भाग्य से बाहर हैं। आपको अपने screwक्षेत्र को फिर से लिखना होगा । मान लें कि इस कार में एक दर्जन स्क्रू का उपयोग किया गया है, और उनमें से प्रत्येक में अलग-अलग निजी तरीकों में कुछ अपरिहार्य आरंभीकरण कोड शामिल हैं, और ये स्क्रू सभी निजी चिह्नित हैं। इस बिंदु पर, यह चूसना शुरू कर देता है।

हां, आप मुझसे तर्क कर सकते हैं कि अच्छी तरह से पुस्तकालय लेखक बेहतर कोड लिख सकता है, इसलिए निजी क्षेत्रों में कुछ भी गलत नहीं है । मैं यह तर्क नहीं दे रहा हूं कि निजी क्षेत्र ओओपी के साथ एक समस्या है । यह एक समस्या है जब लोग उनका उपयोग कर रहे हैं।

कहानी का नैतिक है, यदि आप एक पुस्तकालय लिख रहे हैं, तो आप कभी नहीं जानते कि क्या आपके उपयोगकर्ता किसी विशेष क्षेत्र तक पहुंचना चाहते हैं। यदि आप अनिश्चित हैं, protectedतो इसे चिह्नित करें ताकि बाद में हर कोई खुश हो जाए। कम से कम निजी क्षेत्र का दुरुपयोग न करें ।

मैं निक के जवाब का बहुत समर्थन करता हूं।

Comments

निजी क्षेत्रों का उपयोग करना ज्यादातर यह कहता है कि वंशानुक्रम एक वर्ग / वस्तु (यदि विवेक का उपयोग किया जाता है) के एक निश्चित व्यवहार को बदलने के लिए गलत अमूर्तता है। एलटीपी को बदलकर आमतौर पर चुपचाप उल्लंघन किया जा सकता है क्योंकि एपीआई को बदले बिना व्यवहार को बदल दिया जाता है। शानदार जवाब, +1।

— मदार का भूत

प्रचार! Minecraft mods लिखने की कोशिश करने पर प्राइवेट मेरे अस्तित्व का प्रतिबंध है। इसे ठीक करने के लिए परावर्तन या एएसएम का उपयोग करने से अधिक कष्टप्रद कुछ भी नहीं है।

— RecursiveExceptionException

जैसा कि मैंने निक के जवाब को समझा, वह ज्यादातर तरीकों का उल्लेख कर रहा था न कि गुणों का। मैं पूरी तरह सहमत हूं कि हमें हर बार तरीकों को निजी घोषित नहीं करना चाहिए और उन जरूरतों के उपयोग को विचारशील होना चाहिए, लेकिन cmon आप निजी से संरक्षित संपत्तियों को घोषित करने की सलाह क्यों देंगे क्योंकि आप वर्ग को "फिर से लिखना" आसान बनाना चाहते हैं। पूरी तरह से अपनी हताशा को साझा कर रहा हूं क्योंकि मैं 3 पी के दैनिक के साथ काम कर रहा हूं, लेकिन चलो लोगों को ठोस वास्तुकला बनाने के लिए प्रोत्साहित करते हैं और न केवल यह कहते हुए कि "कोड खत्म हो जाएगा बकवास है तो चलो शुरू से ही संरक्षित किया है ताकि हम इसे आसानी से फिर से लिख सकें"। हालांकि मैं आपकी निराशा साझा करता हूं।

— s66662

Answer 4

मैंने कुछ समय पहले एक लेख पढ़ा था जिसमें हर वर्ग को यथासंभव बंद करने की बात की गई थी। जब तक आपको बाहरी दुनिया के लिए कुछ डेटा या कार्यक्षमता को उजागर करने की तत्काल आवश्यकता नहीं है, तब तक सब कुछ अंतिम और निजी बनाएं । बाद में और अधिक अनुमेय होने की गुंजाइश का विस्तार करना हमेशा आसान होता है, लेकिन दूसरे तरीके से नहीं। सबसे पहले संभव के रूप में बहुत सी बातें के रूप में बनाने पर विचार finalजो बीच चयन कर देगा privateऔर protectedबहुत आसान।

1. जब तक आपको उन्हें तुरंत उप-वर्ग करने की आवश्यकता न हो, तब तक सभी कक्षाओं को अंतिम रूप दें।
2. सभी विधियों को तब तक अंतिम रूप दें, जब तक आपको उन्हें उप-विभाजन करने और उन्हें ओवरराइड करने की आवश्यकता न हो।
3. जब तक आपको विधि के शरीर के भीतर उन्हें बदलने की आवश्यकता न हो, तब तक सभी विधि पैरामीटर को अंतिम रूप दें, जो कि वैसे भी अधिकांश समय थोड़े अजीब होते हैं।

अब अगर आप एक अंतिम वर्ग के साथ रह गए हैं, तो सब कुछ निजी बना दें जब तक कि दुनिया में किसी चीज की बिल्कुल जरूरत न हो - उसे सार्वजनिक करें।

यदि आपके पास एक वर्ग है जिसे उपवर्ग (तों) के साथ छोड़ दिया गया है, तो प्रत्येक संपत्ति और विधि की सावधानीपूर्वक जांच करें। पहले विचार करें कि क्या आप उस संपत्ति / विधि को उपवर्गों में उजागर करना चाहते हैं। यदि आप करते हैं, तो विचार करें कि क्या उपवर्ग आपकी संपत्ति पर कहर बरपा सकता है, अगर यह ओवरराइडिंग की प्रक्रिया में संपत्ति के मूल्य या विधि कार्यान्वयन को गड़बड़ कर देता है। यदि यह संभव है, और आप अपनी कक्षा की संपत्ति / विधि को उपवर्गों (यहां तक ​​कि व्यंग्यात्मक, मुझे पता है) से भी सुरक्षित रखना चाहते हैं, तो इसे निजी बनाएं। अन्यथा इसे संरक्षित करें।

अस्वीकरण: मैं जावा में ज्यादा प्रोग्राम नहीं करता हूं :)

Comments

स्पष्ट करने के लिए: final classजावा में एक वर्ग है जिसे विरासत में नहीं दिया जा सकता है। A final methodगैर-आभासी है, यानी एक उपवर्ग द्वारा अधिलेखित नहीं है (जावा तरीके डिफ़ॉल्ट रूप से आभासी हैं)। A final field/parameter/variableएक अपरिवर्तनीय चर संदर्भ है (इस अर्थ में कि इसे प्रारंभ होने के बाद संशोधित नहीं किया जा सकता है)।

— M.Stramm

मजेदार रूप से पर्याप्त, मैंने सटीक विपरीत सलाह देखी है, कि कुछ भी अंतिम नहीं होना चाहिए जब तक कि यह निश्चित न हो कि प्रश्न में बात को ओवरराइड करने से किसी अपरिवर्तनीय को तोड़ने की क्षमता है। इस तरह से कोई भी अपनी कक्षाओं को आवश्यकतानुसार बढ़ाने के लिए स्वतंत्र है।

— गॉर्डन M

क्या आप अपने प्रोग्रामिंग करियर में एक मामले को नाम दे सकते हैं जहां एक विधि पैरामीटर "फाइनल" को चिह्नित करने से आपकी समझ पर फर्क पड़ा है? (संकलक द्वारा आवश्यक होने पर अन्य)

— user949300

Answer 5

आप कब इस्तेमाल करेंगे privateऔर कब इस्तेमाल करेंगे protected?

प्राइवेट इनहेरिटेंस को आईएस-ए रिश्ते के बजाय रिश्ते के संदर्भ में लागू किया जा सकता है । सीधे शब्दों में कहें तो, इनहेरिटिंग क्लास के बाहरी इंटरफ़ेस का विरासत वाले वर्ग से कोई (दृश्य) संबंध नहीं है, यह privateविरासत का उपयोग केवल एक समान कार्यक्षमता को लागू करने के लिए करता है जो बेस क्लास प्रदान करता है।

इसके विपरीत, निजी वंशानुक्रम, संरक्षित वंशानुक्रम वंशानुक्रम का प्रतिबंधित रूप है, जिसमें व्युत्पन्न वर्ग IS-A एक प्रकार का आधार वर्ग है और यह व्युत्पन्न सदस्यों की पहुँच केवल व्युत्पन्न वर्ग तक सीमित रखना चाहता है।

Comments

वह "रिश्ते के मामले में लागू" एक एचएएस-ए संबंध है। यदि सभी विशेषताएँ निजी हैं, तो उन्हें एक्सेस करने का एकमात्र तरीका है। यह एक ही बात है जैसे कि उप-वर्ग में सुपर-क्लास की एक वस्तु शामिल थी। अपने ठोस वर्गों से सभी संरक्षित विशेषताओं को खत्म करने का मतलब है कि उनमें से भी सभी विरासत को समाप्त करना।

— शनहॉर्की

दिलचस्प विचार प्रक्रिया - निजी विरासत । @shawcorecorey ने यह स्पष्ट करने के लिए धन्यवाद कि यह एचएएस-ए संबंध उर्फ ​​एसोसिएशन (जो एकत्रीकरण या रचना हो सकता है) की ओर इशारा कर रहा है । मुझे लगता है कि इस पोस्ट को भी स्पष्ट करने के लिए अपडेट किया जाना चाहिए।

— RBT

Answer 6

वैसे यह सब एनकैप्सुलेशन के बारे में है अगर paybill classes भुगतान की बिलिंग को संभालती है तो उत्पाद वर्ग में इसे बिलिंग प्रक्रिया की पूरी प्रक्रिया की आवश्यकता है अर्थात भुगतान विधि कैसे भुगतान करें जहां भुगतान करना है। उन लोगों के लिए इससे अधिक कुछ भी नहीं है, जहां अन्य वर्ग भी उपयोग करेंगे, केवल उन वर्गों के लिए जो सीमा तक विस्तारित हैं। जैसा कि आप मदार उचिहा निजी हैं जैसे "limboo"आप इसे देख सकते हैं (आप केवल एकल वर्ग)।