मैं ओओपी/PHP के लिए नया हूँ। कक्षाओं में दृश्यता और विस्तारशीलता की व्यावहारिकता क्या है?

Question

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

Answer 1

यह सब encapsulation के लिए नीचे आता है। इसका मतलब है कक्षा के अंदरूनी छुपाएं और सिर्फ यह बताएं कि यह क्या करता है। यदि आप क्रेडिट कार्ड प्रसंस्करण कक्षा चाहते हैं, तो आप वास्तव में क्रेडिट कार्ड को संसाधित नहीं करते हैं। आप बस जाने में सक्षम होना चाहते हैं: $creditCardProcessor->charge(10.99, $creditCardNumber); और इसे काम करने की उम्मीद है।

कुछ तरीकों से सार्वजनिक और दूसरों को निजी या संरक्षित करके, हम दूसरों के लिए प्रवेश मार्ग छोड़ देते हैं ताकि वे जान सकें कि कोड कहां सुरक्षित है। सार्वजनिक विधियों और चर को 'इंटरफ़ेस' कहा जाता है।

किसी भी कक्षा के लिए, आपके पास कार्यान्वयन है। इस प्रकार कक्षा अपना कर्तव्य रखती है। यदि यह एक चिकनी बनाने वाला वर्ग है, तो कक्षा कैसे सामग्री जोड़ती है, इसमें कौन सी सामग्री जोड़ती है, आदि कार्यान्वयन का हिस्सा हैं। बाहरी कोड को कार्यान्वयन के बारे में पता नहीं होना चाहिए और/या देखभाल नहीं करनी चाहिए।

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

Answer 2

हम निजी विधियां बनाते हैं ताकि हमारे वर्ग के उपभोक्ताओं को कार्यान्वयन के विवरणों की परवाह नहीं करनी पड़े - वे हमारे वर्गों को उनके लिए उपलब्ध कुछ निफ्टी चीजों पर ध्यान केंद्रित कर सकते हैं।

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

कहें कि आपके पास Queue कक्षा है - प्रत्येक बार जब कोई कॉलर कतार में कोई आइटम जोड़ता है, तो कतार की क्षमता में वृद्धि करना आवश्यक हो सकता है। अंतर्निहित कार्यान्वयन के कारण, क्षमता निर्धारित करना मामूली नहीं है, इसलिए आप इसे Enqueue फ़ंक्शन की पठनीयता में सुधार के लिए एक अलग फ़ंक्शन में विभाजित करते हैं। चूंकि कॉलर्स को कतार की क्षमता की परवाह नहीं है (आप इसे उनके लिए संभालने वाले हैं), आप विधि को निजी बना सकते हैं: कॉलर्स अनावश्यक तरीकों से विचलित नहीं होते हैं, आपको चिंता करने की ज़रूरत नहीं है कि कॉलर्स हास्यास्पद चीजें करेंगे क्षमता के लिए, और जब भी आप अपनी कक्षा का उपयोग करने वाले कोड को तोड़ने के बिना किसी भी समय कार्यान्वयन को बदल सकते हैं (जब तक यह अभी भी आपकी कक्षा द्वारा परिभाषित सीमित उपयोग मामलों में क्षमता निर्धारित करता है)।

Answer 3

encapsulation का उपयोग करने के कई कारण हैं, सबसे मजबूत में से एक है: किसी और द्वारा लिखी गई एक बड़ी, जटिल लाइब्रेरी का उपयोग करके कल्पना करें। यदि प्रत्येक ऑब्जेक्ट असुरक्षित था तो आप अनजाने में उन मूल्यों तक पहुंच या परिवर्तन कर सकते थे जिन्हें डेवलपर ने इस तरह से छेड़छाड़ नहीं किया था।

छिपाने वाला डेटा प्रोग्राम को संकल्पनात्मक और कार्यान्वित करने में आसान बनाता है।

Answer 4

यह सब encapsulation के बारे में है। तरीके निजी हैं जो चीजों को आसान बनाने वाले सुंदर कार्यों को उजागर करते हुए आंतरिक गंदगी कार्य करते हैं। जैसे आपके पास एक $ product-> insert() फ़ंक्शन हो सकता है जो सिंगलटन डीबी ऑब्जेक्ट को सत्यापित करने के लिए 4 आंतरिक कार्यों का उपयोग करता है, क्वेरी को सुरक्षित बनाता है, आदि - वे आंतरिक कार्य होते हैं जिन्हें प्रकट करने की आवश्यकता नहीं होती है और यदि कॉल किया जाता है, तो गड़बड़ हो सकती है अन्य संरचनाएं या आपको बहती हैं, डेवलपर, जगह में डाल दिया है।

Answer 5

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

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

आम तौर पर, आप चीजें सार्वजनिक करते हैं, उतना ही आपको अन्य कोड के साथ संगतता के बारे में चिंता करने की ज़रूरत है।

Answer 6

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

कक्षा गुणों के साथ यह काफी समान है। हां, आप सभी सार्वजनिक कक्षाएं लिख सकते हैं, लेकिन इसमें मजा क्या है?

Answer 7

एक बहु डेवलपर स्थिति सिर्फ ताकि आप नहीं गंदगी अपने काम गलती करते हैं (नहीं गंदगी अन्य लोगों के काम करने के लिए), या?

मुख्य रूप से इन दो चीजें। सार्वजनिक रूप से एक विधि बनाना "इस प्रकार वर्ग को अपने ग्राहकों द्वारा उपयोग किया जाना चाहिए", यह निजी बनाने के लिए कहता है "यह एक कार्यान्वयन विस्तार है जो चेतावनी के बिना बदल सकता है और किन ग्राहकों को परवाह नहीं करनी चाहिए" और ग्राहकों को इसका पालन करने के लिए मजबूर करता है सलाह।

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

Answer 8

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

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