यह एक महत्वपूर्ण बिंदु है, लेकिन IMHO समझने लायक है।
सभी OO भाषाएँ हमेशा संदर्भों की प्रतिलिपि बनाती हैं, और कभी भी किसी वस्तु को 'अदृश्य रूप से' कॉपी नहीं करती हैं। यदि OO भाषाएँ किसी अन्य तरीके से काम करती हैं तो कार्यक्रम लिखना अधिक कठिन होगा । उदाहरण के लिए, फ़ंक्शंस और विधियाँ, कभी भी किसी ऑब्जेक्ट को अपडेट नहीं कर सकते हैं। जावा, और अधिकांश OO भाषाओं को महत्वपूर्ण जोड़ा जटिलता के बिना उपयोग करना लगभग असंभव होगा।
एक कार्यक्रम में एक वस्तु का कुछ अर्थ माना जाता है। उदाहरण के लिए यह वास्तविक भौतिक दुनिया में कुछ विशिष्ट का प्रतिनिधित्व करता है। यह आमतौर पर एक ही चीज़ के कई संदर्भों को समझ में आता है। उदाहरण के लिए, मेरे घर का पता कई लोगों और संगठनों को दिया जा सकता है, और यह पता हमेशा एक ही भौतिक स्थान को संदर्भित करता है। तो पहला बिंदु यह है कि वस्तुएं अक्सर किसी ऐसी चीज का प्रतिनिधित्व करती हैं जो विशिष्ट, वास्तविक या ठोस है; और इसलिए एक ही चीज़ के कई संदर्भ होने में सक्षम होना बेहद उपयोगी है। अन्यथा कार्यक्रम लिखना कठिन होगा।
हर बार जब आप aकिसी अन्य फ़ंक्शन के लिए एक तर्क / पैरामीटर के रूप में पास करते हैं, जैसे कॉल
foo(Dog aDoggy);
या किसी विधि को लागू करने के लिए a, अंतर्निहित प्रोग्राम कोड संदर्भ की एक प्रतिलिपि बनाता है, उसी ऑब्जेक्ट के लिए दूसरा संदर्भ उत्पन्न करने के लिए।
इसके अलावा, यदि एक कॉपी किए गए संदर्भ के साथ कोड एक अलग थ्रेड में है, तो दोनों को समान वस्तु तक पहुंचने के लिए समवर्ती रूप से उपयोग किया जा सकता है।
इसलिए अधिकांश उपयोगी कार्यक्रमों में, एक ही वस्तु के कई संदर्भ होंगे, क्योंकि अधिकांश ओओ प्रोग्रामिंग भाषाओं का शब्दार्थ है।
अब, अगर हम इसके बारे में सोचते हैं, क्योंकि संदर्भ से गुजरना कई OO भाषाओं में उपलब्ध एकमात्र तंत्र है (C ++ दोनों का समर्थन करता है), हम इसे 'सही' डिफ़ॉल्ट व्यवहार होने की उम्मीद कर सकते हैं।
IMHO, संदर्भों का उपयोग करना कुछ कारणों से सही डिफ़ॉल्ट है:
- यह गारंटी देता है कि दो अलग-अलग स्थानों में उपयोग की जाने वाली वस्तु का मूल्य समान है। एक वस्तु को दो अलग-अलग डेटा संरचनाओं (सरणियों, सूचियों आदि) में डालने की कल्पना करें, और एक वस्तु पर कुछ संचालन करना जो इसे बदलता है। यह डिबग करने का एक बुरा सपना हो सकता है। इससे भी महत्वपूर्ण बात, यह है दोनों डेटा संरचनाओं में एक ही वस्तु, या प्रोग्राम एक बग है।
- आप कोड को कई कार्यों में खुशी से रिफ्लेक्टर कर सकते हैं, या कई कार्यों में से कोड को एक में विलय कर सकते हैं, और शब्दार्थ नहीं बदलते हैं। यदि भाषा ने संदर्भ शब्दार्थ प्रदान नहीं किया, तो कोड को संशोधित करना और भी जटिल होगा।
एक दक्षता तर्क भी है; संपूर्ण वस्तुओं की प्रतियां बनाना किसी संदर्भ की नकल करने से कम कुशल नहीं है। हालांकि, मुझे लगता है कि बात याद आती है। एक ही वस्तु के कई संदर्भ अधिक अर्थ देते हैं, और उपयोग करने में आसान होते हैं, क्योंकि वे वास्तविक भौतिक दुनिया के शब्दार्थों से मेल खाते हैं।
तो, IMHO, यह आमतौर पर एक ही वस्तु के लिए कई संदर्भों को समझने के लिए समझ में आता है। असामान्य मामलों में जहां एल्गोरिथम के संदर्भ में इसका कोई मतलब नहीं है, ज्यादातर भाषाएं 'क्लोन' या गहरी प्रतिलिपि बनाने की क्षमता प्रदान करती हैं। हालाँकि यह डिफ़ॉल्ट नहीं है।
मुझे लगता है कि जो लोग तर्क देते हैं कि यह डिफ़ॉल्ट नहीं होना चाहिए एक भाषा का उपयोग कर रहे हैं जो स्वचालित कचरा संग्रह प्रदान नहीं करता है। उदाहरण के लिए, पुराने जमाने सी ++। मुद्दा यह है कि उन्हें 'मृत' वस्तुओं को इकट्ठा करने का एक तरीका खोजने की आवश्यकता है और उन वस्तुओं को पुनः प्राप्त नहीं करना चाहिए जो अभी भी आवश्यक हो सकते हैं; एक ही वस्तु के कई संदर्भ होने से यह कठिन हो जाता है।
मुझे लगता है, अगर C ++ में पर्याप्त रूप से कम लागत वाला कचरा संग्रह था, ताकि सभी संदर्भित वस्तुओं को कचरा एकत्र किया जाए, तो बहुत अधिक आपत्ति हो जाती है। अभी भी कुछ मामले होंगे जहाँ संदर्भ शब्दार्थ की आवश्यकता नहीं है। हालांकि, मेरे अनुभव में, जो लोग उन स्थितियों की पहचान कर सकते हैं, वे आम तौर पर वैसे भी उपयुक्त शब्दार्थ चुनने में सक्षम होते हैं।
मेरा मानना है कि कुछ सबूत हैं कि C ++ प्रोग्राम में कोड की एक बड़ी मात्रा कचरा संग्रह को संभालने या कम करने के लिए है। हालाँकि, उस तरह के 'इन्फ्रास्ट्रक्चरल' कोड को लिखना और बनाए रखना लागत जोड़ता है; भाषा का उपयोग करना, या अधिक मजबूत बनाना आसान है। इसलिए, उदाहरण के लिए, गो भाषा को C ++ की कुछ कमजोरियों को दूर करने पर ध्यान केंद्रित करके बनाया गया है, और इसमें कचरा संग्रहण के अलावा कोई विकल्प नहीं है।
यह जावा के संदर्भ में निश्चित रूप से अप्रासंगिक है। यह भी उपयोग करने के लिए आसान होने के लिए डिज़ाइन किया गया था, और इसलिए कचरा संग्रह है। इसलिए कई संदर्भों का होना डिफ़ॉल्ट शब्दार्थ है, और इस अर्थ में अपेक्षाकृत सुरक्षित है कि वस्तुओं का पुन: दावा नहीं किया जाता है जबकि उनका संदर्भ है। बेशक वे एक डेटा संरचना द्वारा आयोजित किया जा सकता है क्योंकि कार्यक्रम ठीक से साफ नहीं है जब यह वास्तव में एक वस्तु के साथ समाप्त हो गया है।
तो, अपने प्रश्न (सामान्यीकरण के एक बिट के साथ) के चारों ओर चक्कर लगाते हुए, जब आप एक ही वस्तु के लिए एक से अधिक संदर्भ चाहते हैं? मैं हर स्थिति में बहुत सोच सकता हूं। वे अधिकांश भाषा पैरामीटर गुजरती तंत्र के डिफ़ॉल्ट शब्दार्थ हैं। मेरा सुझाव है कि क्योंकि वास्तविक दुनिया में मौजूद वस्तुओं को संभालने के डिफ़ॉल्ट शब्दार्थ को संदर्भ के अनुसार होना चाहिए ('वास्तविक वस्तुएं बाहर हैं)।
किसी भी अन्य शब्दार्थ को संभालना कठिन होगा।
Dog a = new Dog("rover"); // initialise with name
DogList dl = new DogList()
dl.add(a)
...
a.setOwner("Mr Been")
मेरा सुझाव है कि "रोवर" dlको उन setOwnerकार्यक्रमों से प्रभावित होना चाहिए, जिन्हें लिखना, समझना, डीबग करना या संशोधित करना मुश्किल है। मुझे लगता है कि अधिकांश प्रोग्रामर हैरान या निराश होंगे।
बाद में, कुत्ते को बेच दिया जाता है:
soldDog = dl.lookupOwner("rover", "Mr Been")
soldDog.setOwner("Mr Mcgoo")
इस तरह की प्रोसेसिंग आम और सामान्य है। इसलिए संदर्भ शब्दार्थ डिफ़ॉल्ट हैं क्योंकि यह आमतौर पर सबसे अधिक समझ में आता है।
सारांश: यह हमेशा समझ में आता है कि एक ही वस्तु के कई संदर्भ हैं।