सार्वजनिक विशेषता के बजाय निजी विशेषता को परिभाषित करने के क्या फायदे हैं? निजीकरण विशेषताओं तक पहुंचने और संशोधित करने के लिए मेरे पास विधियों को बनाने का अतिरिक्त कार्य क्यों होना चाहिए यदि मैं उन्हें सार्वजनिक कर सकूं?कक्षा विशेषता घोषणा: निजी बनाम सार्वजनिक
यदि आप गेटर्स/सेटर्स का उपयोग करते हैं तो आप परिवर्तन या पहुंच पर तर्क कर सकते हैं। आप यह मानने के बजाय इनपुट को मान्य कर सकते हैं कि यह हमेशा सही होता है। आप ट्रैक कर सकते हैं कि मूल्य कितनी बार लाया जाता है।
सबसे अधिक, यह अच्छी डिजाइन है। यह आपको कक्षा के डेवलपर, इसका उपयोग करने के तरीके पर अधिक नियंत्रण देता है और दुरुपयोग, दुर्व्यवहार या किसी को कुछ गलत करने से रोकने की अधिक क्षमता देता है।
यदि आप एक्सेस विधि बनाते हैं, तो आप इंटरफ़ेस से कार्यान्वयन को अलग करते हैं।
क्योंकि आपको हमेशा इंटरफ़ेस से कार्यान्वयन की रक्षा करने का प्रयास करना चाहिए। यदि आप कोई विशेषता सार्वजनिक करते हैं, तो आप क्लाइंट को यह बताते हैं कि उस विशेषता के लिए आपका कार्यान्वयन कैसा है।
यह न केवल इंटरफेस को ध्यान में रखते हुए, बल्कि कार्यान्वयन को भी बाध्य करता है।
इसके अलावा, यदि आप किसी विधि का उपयोग करते हैं तो आप अन्य स्मार्ट चीजें जैसे सत्यापन, अभिगम नियंत्रण, लेखांकन कर सकते हैं। यदि आप एक विशेषता सार्वजनिक करते हैं, तो आपके पास उस विशेषता के साथ ग्राहक क्या कर सकता है
एक निजी विशेषता आपको उस विशेषता के लिए, आपकी कक्षा के उपयोगकर्ताओं से सुरक्षा का स्तर प्रदान करती है। यदि आप सार्वजनिक विशेषता का उपयोग करते हैं, तो आपको अमान्य मूल्यों के सामने परीक्षण करने के लिए और अधिक तर्क जोड़ने की आवश्यकता होगी, जो अधिक काम हो सकता है, साथ ही अधिक कम्प्यूटेशनल रूप से महंगा भी हो सकता है।
सार्वजनिक गुण भी इंटरफ़ेस "अव्यवस्था"। आपके द्वारा पेश किए जाने वाले कम सार्वजनिक गुण, "क्लीनर" और आपके ऑब्जेक्ट को आसान बनाना होगा। कुछ विशेषताओं को निजी बनाने से आप आसानी से उपयोग प्रदान करते हुए लचीलापन देते हैं जो अन्यथा वहां नहीं होता है।
सी # में यह मूर्खतापूर्ण है। इसका मतलब है कि सार्वजनिक क्षेत्र आश्चर्यजनक होंगे, और अन्य लोगों को आपके कोड को समझने में थोड़ा समय लगेगा।
कारण यह है कि मूर्खतापूर्ण लोगों को अन्य स्पष्टीकरणों के साथ क्या करना है, लेकिन तथ्य यह है कि यह मूर्खतापूर्ण माध्यम है कि आपको किसी सार्वजनिक क्षेत्र में संपत्ति पसंद नहीं करनी चाहिए जब तक कि किसी क्षेत्र का उपयोग करने के लिए कोई अनिवार्य कारण न हो।
अल्प अवधि में ओओपी शुद्धियों को नाखुश बनाने के अलावा कोई भी नहीं है।
(मुझे लगता है कि आप उन गुणों को उजागर करने का मतलब रखते हैं जो अन्यथा गेटर्स/सेटर्स का उपयोग करते हैं - जाहिर है यदि आप अपने सभी गुणों को सार्वजनिक करते हैं तो एक बड़ा अंतर होता है)।
लंबी अवधि में ऐसा करने के कुछ अच्छे कारण हैं।
सबसे पहले यह आपको हार्डवेयर ब्रेकपॉइंट्स और ब्लैक-जादू के संयोजन के साथ उत्पत्ति को पीछे ट्रैक करने के बजाय इसके स्रोत पर इनपुट को सत्यापित करने की अनुमति देता है।
उदा।
void Foo::setWeight(float weight)
{
ASSERTMSG(weight >= 0.0f && weight <= 1.0f, "Weights must fall in [0..1]");
mWeight = weight;
}
यह आपको बाद में क्लाइंट कोड को पुन: सक्रिय करने की आवश्यकता के बिना आपके ऑब्जेक्ट के व्यवहार को बदलने की अनुमति देता है।
उदा।
void Foo::setSomething(float thing)
{
mThing = thing;
// 2009/4/2: turns out we need to recalc a few things when this changes..
...
}
मुख्य रूप से encapsulation की ओओ अवधारणा के कारण। निजी का उपयोग करके आप ऑब्जेक्ट स्थिति के नियंत्रण को रखते हुए अपने ऑब्जेक्ट वैरिएबल तक पहुंच को समाहित करते हैं। बाहरी ऑब्जेक्ट्स को आपके ऑब्जेक्ट की स्थिति बदलने की इजाजत नहीं है जिसे आप जानते नहीं हैं।
एक साधारण उदाहरण पॉकेट ऑब्जेक्ट होगा।
class Pocket {
public int numberOfCoins = 10;
private boolean haveMoney = true;
public void giveOneCoin(){
if(stillHaveMoney()){
numberOfCoins--;
if(numberOfCoins=<0){
haveMoney=false;
}
}
}
public boolean stillHaveMoney(){
return haveMoney;
}
}
और अब नीचे किसी अन्य वर्ग की कल्पना:
class PickPockets {
public void getSomeMoney(Pocket pocket){
pocket.numberOfCoins=0;
}
}
निश्चित रूप से यह एक सरल उदाहरण है। हालांकि यह दिखाता है कि आपके वर्ग फ़ील्ड/विशेषताओं तक पहुंच का नियंत्रण रखना महत्वपूर्ण है। अधिक जटिल स्थिति के साथ एक और जटिल वस्तु की कल्पना करो। Encapsulation वस्तु की अमूर्तता और स्थिरता बेहतर बनाता है।
येर, लेकिन आखिरी बार कब आपकी कक्षाओं में से एक बदमाश हो गया और अन्य वस्तुओं से धन चोरी करना शुरू कर दिया? – fauxCoder
भविष्य में जब कोड बड़ा होता है और कोई कोड का उपयोग करना चाहता है, तो कोई भी संख्या देख सकता है किऑफ सिक्के विशेषता सार्वजनिक है और परिणाम प्राप्त करने के लिए इसे सीधे बदलें। लेकिन फिर जब वे मनी फ़ंक्शन को सटीक मानते हैं, तो उन्हें गलत परिणाम मिल सकता है। – kiwicomb123
आम तौर पर आप उन फ़ील्ड के लिए निजी घोषणाओं का उपयोग करेंगे जिन्हें आप अपने प्रोग्राम के तर्क में अलग करना चाहते हैं, केवल तभी यदि आप आवश्यक मानते हैं।
सार्वजनिक घोषणाएं आपको अपने कार्यक्रम के प्रवाह पर अधिक नियंत्रण देती हैं; जब भी आप चाहें सार्वजनिक क्षेत्र बदल सकते हैं। आप घर में आदमी हैं।
तो, अधिकांश लोग निजी घोषणाओं के लिए एक बड़े हां के साथ सहज प्रतिक्रिया क्यों देते हैं?
क्योंकि:
नीचे की रेखा आश्चर्यजनक रूप से "वाणिज्यिक" है !! यदि आप इसे "बेच रहे हैं", तो निजी जाओ, अन्यथा जो भी आपको पसंद है वह करें।
यदि आप सभी गुण निजी हैं तो आप लंबी अवधि में बेहतर हैं। इसमें गेटर्स का उपयोग नहीं करना शामिल है। यदि आप ऑब्जेक्ट्स के गुणों तक पहुंच रहे हैं तो आप encapsulation तोड़ रहे हैं, और वास्तव में ओओपी नहीं कर रहे हैं। उस समय, कक्षा बनाने के अधिकांश कारण बर्बाद हो गए हैं। घुसपैठियों से बचाने के लिए महल का निर्माण क्यों करें, फिर सभी दरवाजे खुल जाएं? या (गेटर्स के साथ) अनुरोध पर घुसपैठियों का हमेशा स्वागत करते हैं।
"डेमेटर लॉ" और "टेल न पूछें" की पद्धतियां उत्पादन कोड में बग दर को कम करने के लिए दिखायी गई हैं। सार्वजनिक विशेषताओं का उपयोग करने से वस्तु उन्मुख शुद्धवादियों को नाखुश नहीं बनाया जाएगा, यह केवल आपके कोड का उपयोग करके उन्हें रोक देगा।
अपनी वस्तुओं को बताएं कि उनके गुणों के साथ क्या करना है, उन्हें मूल्यों के लिए न पूछें, उन्हें कुशल बनाएं और उन्हें वापस लिखें। यह एक कुत्ते को चलने के लिए ले जाएगा और फिर इसे आगे बढ़ने के लिए अपने पैरों को एक-एक करके उठाएगा।
वैसे, व्यवहार, सभी को सार्वजनिक होना चाहिए। ऐसा लगता है कि किसी भी विधि निजी होना चाहिए वास्तव में एक और वर्ग की एक अनूठी विधि है। उस वर्ग और विधि को निकालें और अपनी आंखों के सामने अपना डिज़ाइन सरल बनाएं।
... और यह वांछनीय क्यों है? – Rob
@Rob फिर कार्यान्वयन पूरी तरह से बदल सकता है, और इंटरफ़ेस का उपयोग करने वाले किसी भी कोड को इसके बारे में कभी भी पता नहीं होना चाहिए। – Kalium