डिलिगेशन (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग): Difference between revisions

From Vigyanwiki
No edit summary
 
(No difference)

Latest revision as of 17:45, 6 October 2023

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग में, डिलिगेशन एक अन्य मूल ऑब्जेक्ट (प्रेषक) के संदर्भ में एक ऑब्जेक्ट (कंप्यूटर विज्ञान) (रिसीवर) के एक अवयव संपत्ति (प्रोग्रामिंग) या प्रणाली (कंप्यूटर प्रोग्रामिंग)) का मूल्यांकन करने के लिए संदर्भित करता है। डिलिगेशन स्पष्ट रूप से किया जा सकता है, भेजने वाली ऑब्जेक्ट को प्राप्त करने वाली ऑब्जेक्ट को पास करके, जो किसी ऑब्जेक्ट उन्मुख भाषा में किया जा सकता है; या निहित रूप से, भाषा के अवयव लुकअप नियमों द्वारा, जिसके लिए सुविधा के लिए भाषा समर्थन की आवश्यकता होती है। वर्ग आधारित प्रोग्रामिंग में इन्हेरिटेंस (ऑब्जेक्ट-उन्मुख प्रोग्रामिंग) के अनुरूप प्रोटोटाइप-आधारित प्रोग्रामिंग में व्यवहार के पुन: उपयोग के लिए अंतर्निहित डिलिगेशन मौलिक प्रणाली है। भाषा के स्तर पर डिलिगेशन का समर्थन करने वाली सबसे प्रसिद्ध भाषाएँ स्व (प्रोग्रामिंग भाषा) हैं, जो कि अपरिवर्तनीय ऑब्जेक्ट पैरेंट स्लॉट (कंप्यूटर आर्किटेक्चर) की अपनी धारणा के माध्यम से डिलिगेशन की धारणा को सम्मिलित करती हैं, जो स्वयं कॉल और जावास्क्रिप्ट पर प्रणाली खोज में उपयोग की जाती हैं; विस्तृत जानकारी के लिए जावास्क्रिप्ट डिलिगेशन देखें।

'डिलिगेशन' शब्द का उपयोग ऑब्जेक्टों के बीच विभिन्न अन्य संबंधों के लिए भी शिथिल रूप से किया जाता है; अधिक जानका के लिए डिलिगेशन (प्रोग्रामिंग) देखें। बार-बार भ्रमित होने वाली अवधारणाएं बस किसी अन्य ऑब्जेक्ट का उपयोग कर रही हैं, जिसे अधिक सटीक रूप से कंसल्टेशन या ऑब्जेक्ट एकत्रीकरण के रूप में संदर्भित किया जाता है; और किसी अन्य ऑब्जेक्ट पर संबंधित अवयव का मूल्यांकन करके एक ऑब्जेक्ट पर एक अवयव का मूल्यांकन करना, विशेष रूप से प्राप्त ऑब्जेक्ट के संदर्भ में, जिसे अधिक सटीक रूप से फॉरवार्डिंग (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग) के रूप में जाना जाता है, (जब एक रैपर ऑब्जेक्ट नहीं होता है) लपेटी हुई ऑब्जेक्ट को पास न करें)।[1][2][lower-alpha 1] डिलिगेशन पैटर्न डेलिगेशन को लागू करने के लिए एक सॉफ्टवेयर डिजाइन पैटर्न है, हालांकि इस शब्द का उपयोग कंसल्टेशन या फॉरवार्डिंग के लिए भी शिथिल रूप से किया जाता है।

अवलोकन

तथाकथित स्व कॉल भेजने के लिए प्रणाली लुकअप नियमों का उपयोग करने वाली प्रोग्रामिंग भाषा सुविधा के रूप में डिलिगेशन की भावना को हेनरी लिबरमैन ने अपने 1986 के पेपर यूजिंग प्रोटोटाइप ऑब्जेक्ट्स टू इम्प्लीमेंट शेयर्ड बिहेवियर इन ऑब्जेक्ट-ओरिएंटेड सिस्टम्स में परिभाषित किया था।

डिलिगेशन डायनेमिक बाइंडिंग (कंप्यूटर साइंस) पर निर्भर है, क्योंकि इसके लिए आवश्यक है कि एक दी गई प्रणाली कॉल रनटाइम पर कोड के विभिन्न खंडों को लागू कर सके।[citation needed]. प्रोग्राम घटकों के व्यवहार को अनुकूलित करने के साधन के रूप में इसका उपयोग मैक-ओएस (और इसके पूर्ववर्ती नेक्स्टस्टेप) में किया जाता है।[3] यह विंडोज़ को प्रबंधित करने के लिए एकल ओएस-प्रदत्त वर्ग का उपयोग करने जैसे कार्यान्वयन को सक्षम करता है, क्योंकि वर्ग एक डिलिगेशन लेता है जो प्रोग्राम-विशिष्ट है और आवश्यकतानुसार डिफ़ॉल्ट व्यवहार को ओवरराइड कर सकता है। उदाहरण के लिए, जब उपयोगकर्ता क्लोज बॉक्स पर क्लिक करता है, तो विंडो प्रबंधक डिलिगेशन को एक विंडोशोल्डक्लोज कॉल भेजता है, और डिलिगेशन विंडो के बंद होने में देरी कर सकता है, यदि विंडो की सामग्री द्वारा सुरक्षित किये गए डेटा का डिलिगेशनत्व नहीं किया जाता है।

डिलिगेशन की विशेषता स्वयं के देर से बाध्यकारी होने के रूप में हो सकती है (और फॉरवार्डिंग (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग) से अलग) :[4]

... messages sent to the self (or this) variable in the parent will "come back" to the object that originally received the message.

वह यह है कि सेल्फ प्राप्त करने वाली ऑब्जेक्ट में एक प्रणाली में परिभाषा समय पर उस ऑब्जेक्ट के लिए स्थिर रूप से बाध्य नहीं है (जैसे संकलन समय या जब फलन किसी ऑब्जेक्ट से जुड़ा होता है), बल्कि मूल्यांकन समय पर, यह मूल ऑब्जेक्ट के लिए बाध्य होता है।

यह तर्क दिया गया है कि प्रोग्राम कोड को अधिक पठनीय और समझने योग्य बनाने के लिए कुछ प्रकरणों में डिलिगेशन को इनहेरिटेंस (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग) के लिए प्राथमिकता दी जा सकती है।[5] स्पष्ट डिलिगेशन काफी व्यापक होने के अतिरिक्त, अपेक्षाकृत कुछ प्रमुख प्रोग्रामिंग भाषाएं इन्हेरिटेंस के वैकल्पिक मॉडल के रूप में डिलिगेशन को लागू करती हैं। डिलिगेशन और इन्हेरिटेंस के बीच सटीक संबंध जटिल है; कुछ लेखक उन्हें समतुल्य मानते हैं, या एक को दूसरे का विशेष प्रकरण मानते हैं।[6]


डिलिगेशन के लिए भाषा समर्थन

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

डिलिगेशन का यह लाभ है कि यह रन टाइम पर हो सकता है और किसी प्रकार की संस्थाओं के केवल एक सबसेट को प्रभावित कर सकता है और रन टाइम पर हटाया भी जा सकता है। इन्हेरिटेंस, इसके विपरीत, सामान्यतः उदाहरणों के अतिरिक्त प्रकार को लक्षित करता है, और संकलन समय तक ही सीमित है। दूसरी ओर, इन्हेरिटेंस को स्थिर रूप से टाइप-चेक किया जा सकता है, जबकि डिलिगेशन सामान्यतः जेनरिक के बिना नहीं हो सकता है (हालांकि डिलिगेशन का प्रतिबंधित संस्करण स्थिर रूप से टाइप-सुरक्षित हो सकता है)[7]). डिलिगेशन को विशिष्ट ऑब्जेक्टों के लिए रन-टाइम इनहेरिटेंस कहा जा सकता है।

यहाँ C शार्प (प्रोग्रामिंग भाषा) | C#/जावा (प्रोग्रामिंग भाषा) जैसी भाषा में एक स्यूडोकोड उदाहरण दिया गया है:

class A {
  void foo() {
    // "this" also known under the names "current", "me" and "self" in other languages
    this.bar();
  }

  void bar() {
    print("a.bar");
  }
};

class B {
  private delegate A a; // delegation link

  public B(A a) {
    this.a = a;
  }

  void foo() {
    a.foo(); // call foo() on the a-instance
  }

  void bar() {
    print("b.bar");
  }
};

a = new A();
b = new B(a); // establish delegation between two objects

कॉलिंग b.foo() के परिणामस्वरूप b.bar मुद्रित होगा, चूँकि this मूल रिसीवर ऑब्जेक्ट को संदर्भित करता है, b, के संदर्भ में a. परिणामी अस्पष्टता this को ऑब्जेक्ट सिज़ोफ्रेनिया कहा जाता है।

निहित अनुवाद this एक स्पष्ट पैरामीटर में, कॉल (in B, साथ a एक डिलिगेशन) a.foo() में अनुवाद करता है, A.foo(b), के प्रकार का उपयोग करना a प्रणाली संकल्प के लिए, लेकिन डिलिगेशन ऑब्जेक्ट b के लिए this तर्क कहा जाता है।

इन्हेरिटेंस का उपयोग करते हुए, अनुरूप कोड (बड़े अक्षरों का उपयोग करके यह जोर देने के लिए कि संकल्प वर्गों पर आधारित है, ऑब्जेक्टों पर नहीं) है:

class A {
  void foo() {
    this.bar();
  }

  void bar() {
    print("A.bar");
  }
};

class B extends A {
  public B() {}

  void foo() {
    super.foo(); // call foo() of the superclass (A)
  }

  void bar() {
    print("B.bar");
  }
};

b = new B();

कॉलिंग b.foo() का परिणाम b.bar होगा। इस प्रकरण में, this असंदिग्ध है: एक ही ऑब्जेक्ट है, b, और this.bar() उपवर्ग पर प्रणाली को हल करता है।

सामान्य रूप से प्रोग्रामिंग लैंग्वेज एक भाषा अवधारणा के रूप में डेलिगेशन के इस असामान्य रूप का समर्थन नहीं करती हैं, लेकिन कुछ अपवाद हैं।[citation needed].

ड्युअल इन्हेरिटेंस

यदि भाषा डिलिगेशन और इन्हेरिटेंस दोनों का समर्थन करती है, तो एक ही समय में दोनों प्रणालियों का उपयोग करके ड्युअल इन्हेरिटेंस कर सकते हैं

class C extends A {
  delegationlink D d;
}

यह प्रणाली लुकअप के लिए अतिरिक्त नियमों की मांग करता है, क्योंकि अब संभावित रूप से दो प्रणालीयां हैं जिन्हें सबसे विशिष्ट (दो लुकअप पथों के कारण) के रूप में दर्शाया जा सकता है।

संबंधित क्षेत्र

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

हाल ही में डिलिगेशन बांटने पर भी काम किया गया है, इसलिए खोज इंजन के ग्राहक (सस्ते होटल के कमरे ढूँढना) सर्वोत्तम हिट और सामान्य पुन: प्रयोज्य कार्यक्षमता साझा करने के लिए डिलिगेशन का उपयोग करके एक साझा इकाई का उपयोग कर सकते हैं।

2003 में अर्न्स्ट और लॉरेंज द्वारा आस्पेक्ट ओरिएंटेड प्रोग्रामिंग सलाह संकल्प के लिए डिलिगेशन का भी सुझाव दिया गया है।

यह भी देखें

अंतर करना:







टिप्पणियाँ

  1. Beck 1997 uses the terms "simple delegation" for when the receiving object does not have access to the sending object, and "self delegation" for when the receiving object does have access to the sending object; in modern language these are "forwarding" and "delegation", as used in this article.


संदर्भ

  1. Gamma et al. 1995, "Delegation", pp. 20–21.
  2. Beck 1997, "Delegation", pp. 64–69.
  3. Apple (2009-08-20). "Cocoa Fundamentals Guide: Delegates and Data Sources". Apple Developer Connection. Retrieved 2009-09-11.
  4. "Intersecting Classes and Prototypes". Perspectives of Systems Informatics: 5th International Andrei Ershov Memorial Conference, PSI 2003, Akademgorodok, Novosibirsk, Russia, July 9-12, 2003, Revised Papers. p. 38.
  5. [1]Trygve Reenskaug, Dept. of Informatics, University of Oslo, "The Case for Readable Code" (2007)
  6. Stein, Lynn Andrea. प्रतिनिधिमंडल विरासत है. OOPSLA '87 Conference proceedings on Object-oriented programming systems, languages and applications. pp. 138–146. doi:10.1145/38807.38820.
  7. Günter Kniesel (1999-11-19). "Type-Safe Delegation for Run-Time Component Adaptation". ECOOP' 99 — Object-Oriented Programming. Lecture Notes in Computer Science. Vol. 1628. Springer. pp. 351–366. CiteSeerX 10.1.1.33.7584. doi:10.1007/3-540-48743-3_16. ISBN 978-3-540-66156-6. Archived from the original on 2015-03-04. Retrieved 2015-03-04. यह पेपर विशुद्ध रूप से अग्रेषण-आधारित वस्तु संरचना के पूरक के रूप में वस्तु-आधारित विरासत (जिसे प्रतिनिधिमंडल के रूप में भी जाना जाता है) का प्रस्ताव करता है। यह एक क्लास-आधारित ऑब्जेक्ट मॉडल में प्रतिनिधिमंडल का एक प्रकार का सुरक्षित एकीकरण प्रस्तुत करता है और दिखाता है कि यह अग्रेषण-आधारित घटक इंटरैक्शन द्वारा सामना की जाने वाली समस्याओं को कैसे दूर करता है, यह कैसे घटकों की स्वतंत्र विस्तारशीलता और अप्रत्याशित, गतिशील घटक अनुकूलन का समर्थन करता है।{{cite book}}: CS1 maint: bot: original URL status unknown (link)


बाहरी संबंध