कम्पोजीशन ओवर इनहेरिटेंस: Difference between revisions
No edit summary |
No edit summary |
||
| Line 2: | Line 2: | ||
{{Cleanup bare URLs|date=August 2022}} | {{Cleanup bare URLs|date=August 2022}} | ||
{{Confusing|date=October 2015}} | {{Confusing|date=October 2015}} | ||
[[File:UML diagram of composition over inheritance.svg|thumb|right|444px|यह आरेख दर्शाता है कि | [[File:UML diagram of composition over inheritance.svg|thumb|right|444px|यह आरेख दर्शाता है कि इनहेरिटेंस डिजाइन सिद्धांत पर रचना का उपयोग करके कैसे एक जानवर के मक्खी और ध्वनि व्यवहार को लचीले विधि से डिजाइन किया जा सकता है।<ref name="FHDPs" />]][[ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग]] ऊप में इनहेरिटेंस पर रचना सिद्धांत या सम्मिश्र पुनः प्रयोग सिद्धांत के रूप में होता है तथा क्लासेस को [[बहुरूपता (कंप्यूटर विज्ञान)|बहुरूपता कंप्यूटर विज्ञान]] व्यवहार और कोड का पुन: उपयोग करना चाहिए तथा उनकी संरचना द्वारा अन्य क्लासेस के उदाहरण देना चाहिए जो किसी आधार या पैरेंट क्लास से प्राप्त [[वंशानुक्रम (कंप्यूटर विज्ञान)|इनहेरिटेंस कंप्यूटर विज्ञान]] के अतिरिक्त वांछित कार्यकार्यात्मकता को कार्यान्वित करते हैं।<ref>{{cite book | ||
| url = https://books.google.com/books?id=4pjbgVHzomsC&q=composite+reuse+principle&pg=PA17 | | url = https://books.google.com/books?id=4pjbgVHzomsC&q=composite+reuse+principle&pg=PA17 | ||
| title = Java Design - Objects, UML, and Process: 1.1.5 Composite Reuse Principle (CRP) | | title = Java Design - Objects, UML, and Process: 1.1.5 Composite Reuse Principle (CRP) | ||
| Line 11: | Line 11: | ||
| isbn = 9780201750447 | | isbn = 9780201750447 | ||
| accessdate = 2012-05-29 | | accessdate = 2012-05-29 | ||
}}</ref> यह | }}</ref> यह ऊप का प्रायः सिद्धांत है, जिसमे कि प्रभावशाली पुस्तक [[डिजाइन पैटर्न्स]] 1994 में हुआ था।<ref>{{Cite book | isbn = 0-201-63361-2 | title = [[Design Patterns|Design Patterns: Elements of Reusable Object-Oriented Software]] | last1 = Gamma | first1 = Erich | authorlink1 = Erich Gamma | last2 = Helm | first2 = Richard | last3 = Johnson | first3 = Ralph | authorlink3 = Ralph Johnson (computer scientist) | last4 = Vlissides | first4 = John | authorlink4 = John Vlissides | year = 1994 | publisher = [[Addison-Wesley]] | page = [https://archive.org/details/designpatternsel00gamm/page/20 20] | oclc = 31171684 }} | ||
</ref> | </ref> | ||
== मूल बातें == | == मूल बातें == | ||
इनहेरिटेंस पर रचना का कार्यान्वयन सामान्यतः विभिन्न इंटरफ़ेस (कंप्यूटिंग) के निर्माण के साथ प्रारंभ होता है # ऑब्जेक्ट-ओरिएंटेड भाषाओं में उन व्यवहारों का प्रतिनिधित्व करता है जिन्हें सिस्टम को प्रदर्शित करना चाहिए। इंटरफेस बहुरूपता (कंप्यूटर विज्ञान) व्यवहार को सुविधाजनक बना सकते हैं। पहचाने गए इंटरफेस को लागू करने वाली क्लासेस एं आवश्यकतानुसार व्यावसायिक डोमेन क्लासेस में बनाई और जोड़ी जाती हैं। इस प्रकार, सिस्टम व्यवहार विरासत के बिना अनुभव किए जाते हैं। | |||
वास्तव में, व्यावसायिक डोमेन | वास्तव में, व्यावसायिक डोमेन क्लास बिना किसी इनहेरिटेंस के आधार क्लास हो सकते हैं। सिस्टम व्यवहारों का वैकल्पिक कार्यान्वयन एक अन्य क्लास प्रदान करके पूरा किया जाता है जो वांछित व्यवहार इंटरफ़ेस को लागू करता है। एक क्लास जिसमें एक इंटरफ़ेस का संदर्भ होता है, इंटरफ़ेस के कार्यान्वयन का समर्थन कर सकता है - एक विकल्प जिसे [[रनटाइम (कार्यक्रम जीवनचक्र चरण)]] तक विलंबित किया जा सकता है। | ||
== उदाहरण == | == उदाहरण == | ||
| Line 26: | Line 24: | ||
<वाक्यविन्यास लैंग = सीपीपी> | <वाक्यविन्यास लैंग = सीपीपी> | ||
क्लास वस्तु | |||
{ | { | ||
जनता: | जनता: | ||
| Line 42: | Line 40: | ||
}; | }; | ||
क्लास दृश्यमान: सार्वजनिक वस्तु | |||
{ | { | ||
मॉडल * मॉडल; | मॉडल * मॉडल; | ||
| Line 60: | Line 58: | ||
}; | }; | ||
जंगम | जंगम क्लास : सार्वजनिक वस्तु | ||
{ | { | ||
जनता: | जनता: | ||
| Line 69: | Line 67: | ||
</वाक्यविन्यास हाइलाइट> | </वाक्यविन्यास हाइलाइट> | ||
फिर, मान लीजिए कि हमारे पास ये ठोस | फिर, मान लीजिए कि हमारे पास ये ठोस क्लास भी हैं: | ||
* | * क्लासेस {{code|Player}} - जो है {{code|Solid}}, {{code|Movable}} और {{code|Visible}} | ||
* | * क्लासेस {{code|Cloud}} - जो है {{code|Movable}} और {{code|Visible}}, लेकिन नहीं {{code|Solid}} | ||
* | * क्लासेस {{code|Building}} - जो है {{code|Solid}} और {{code|Visible}}, लेकिन नहीं {{code|Movable}} | ||
* | * क्लासेस {{code|Trap}} - जो है {{code|Solid}}, लेकिन नहीं {{code|Visible}} और न {{code|Movable}} | ||
ध्यान दें कि मल्टीपल इनहेरिटेंस खतरनाक है यदि सावधानी से लागू नहीं किया गया है क्योंकि इससे मल्टीपल इनहेरिटेंस#द डायमंड प्रॉब्लम हो सकती है। इसका एक समाधान इस प्रकार की | ध्यान दें कि मल्टीपल इनहेरिटेंस खतरनाक है यदि सावधानी से लागू नहीं किया गया है क्योंकि इससे मल्टीपल इनहेरिटेंस#द डायमंड प्रॉब्लम हो सकती है। इसका एक समाधान इस प्रकार की क्लासेस एं बनाना है {{code|VisibleAndSolid}}, {{code|VisibleAndMovable}}, {{code|VisibleAndSolidAndMovable}}, आदि हर आवश्यक संयोजन के लिए; चूंकि , यह बड़ी मात्रा में दोहराव वाले कोड की ओर ले जाता है। C ++ मल्टीपल इनहेरिटेंस की डायमंड प्रॉब्लम को हल करने के लिए [[आभासी विरासत]] का उपयोग करता है। | ||
=== संरचना और इंटरफेस === | === संरचना और इंटरफेस === | ||
इस खंड में सी ++ उदाहरण कोड पुन: उपयोग और बहुरूपता प्राप्त करने के लिए संरचना और इंटरफेस का उपयोग करने के सिद्धांत को प्रदर्शित करता है। सी ++ भाषा में इंटरफेस घोषित करने के लिए एक समर्पित कीवर्ड नहीं होने के कारण, निम्न सी ++ उदाहरण शुद्ध [[सार आधार वर्ग]] से विरासत का उपयोग करता है। अधिकांश उद्देश्यों के लिए, यह कार्यात्मक रूप से जावा और सी # जैसी अन्य भाषाओं में प्रदान किए गए इंटरफेस के बराबर है। | इस खंड में सी ++ उदाहरण कोड पुन: उपयोग और बहुरूपता प्राप्त करने के लिए संरचना और इंटरफेस का उपयोग करने के सिद्धांत को प्रदर्शित करता है। सी ++ भाषा में इंटरफेस घोषित करने के लिए एक समर्पित कीवर्ड नहीं होने के कारण, निम्न सी ++ उदाहरण शुद्ध [[सार आधार वर्ग|सार आधार क्लास]] से विरासत का उपयोग करता है। अधिकांश उद्देश्यों के लिए, यह कार्यात्मक रूप से जावा और सी # जैसी अन्य भाषाओं में प्रदान किए गए इंटरफेस के बराबर है। | ||
नामक एक अमूर्त | नामक एक अमूर्त क्लास का परिचय दें {{code|VisibilityDelegate}}, उपक्लासेस के साथ {{code|NotVisible}} और {{code|Visible}}, जो किसी वस्तु को खींचने का साधन प्रदान करता है: | ||
<वाक्यविन्यास लैंग = सीपीपी> | <वाक्यविन्यास लैंग = सीपीपी> | ||
क्लास दृश्यता प्रतिनिधि | |||
{ | { | ||
जनता: | जनता: | ||
| Line 97: | Line 95: | ||
}; | }; | ||
क्लास दृश्यमान: सार्वजनिक दृश्यता प्रतिनिधि | |||
{ | { | ||
जनता: | जनता: | ||
| Line 106: | Line 104: | ||
</वाक्यविन्यास हाइलाइट> | </वाक्यविन्यास हाइलाइट> | ||
नामक एक अमूर्त | नामक एक अमूर्त क्लास का परिचय दें {{code|UpdateDelegate}}, उपक्लासेस के साथ {{code|NotMovable}} और {{code|Movable}}, जो किसी वस्तु को स्थानांतरित करने का साधन प्रदान करता है: | ||
<वाक्यविन्यास लैंग = सीपीपी> | <वाक्यविन्यास लैंग = सीपीपी> | ||
क्लास अद्यतन प्रतिनिधि | |||
{ | { | ||
जनता: | जनता: | ||
| Line 132: | Line 130: | ||
</वाक्यविन्यास हाइलाइट> | </वाक्यविन्यास हाइलाइट> | ||
नामक एक अमूर्त | नामक एक अमूर्त क्लास का परिचय दें {{code|CollisionDelegate}}, उपक्लासेस के साथ {{code|NotSolid}} और {{code|Solid}}, जो किसी वस्तु से टकराने का साधन प्रदान करता है: | ||
<वाक्यविन्यास लैंग = सीपीपी> | <वाक्यविन्यास लैंग = सीपीपी> | ||
क्लास टकराव प्रतिनिधि | |||
{ | { | ||
जनता: | जनता: | ||
| Line 158: | Line 156: | ||
</वाक्यविन्यास हाइलाइट> | </वाक्यविन्यास हाइलाइट> | ||
अंत में, नाम की एक | अंत में, नाम की एक क्लासेस का परिचय दें {{code|Object}} इसकी दृश्यता को नियंत्रित करने के लिए सदस्यों के साथ (ए {{code|VisibilityDelegate}}), चलनशीलता (एक का उपयोग करके {{code|UpdateDelegate}}), और दृढ़ता (ए का उपयोग करके {{code|CollisionDelegate}}). इस क्लास में ऐसी विधियाँ हैं जो इसके सदस्यों को सौंपती हैं, उदा। {{code|update()}} बस पर एक विधि कहते हैं {{code|UpdateDelegate}}: | ||
<वाक्यविन्यास लैंग = सीपीपी> | <वाक्यविन्यास लैंग = सीपीपी> | ||
क्लास वस्तु | |||
{ | { | ||
दृश्यता प्रतिनिधि* _v; | दृश्यता प्रतिनिधि* _v; | ||
| Line 188: | Line 186: | ||
</वाक्यविन्यास हाइलाइट> | </वाक्यविन्यास हाइलाइट> | ||
फिर, ठोस | फिर, ठोस क्लासेस एं दिखेंगी: | ||
<वाक्यविन्यास लैंग = सीपीपी> | <वाक्यविन्यास लैंग = सीपीपी> | ||
| Line 201: | Line 199: | ||
}; | }; | ||
क्लास धुआँ: सार्वजनिक वस्तु | |||
{ | { | ||
जनता: | जनता: | ||
| Line 213: | Line 211: | ||
== लाभ == | == लाभ == | ||
इनहेरिटेंस पर रचना का पक्ष लेना [[एक]] डिज़ाइन सिद्धांत है जो डिज़ाइन को उच्च लचीलापन देता है। उनके बीच समानता खोजने और पारिवारिक पेड़ बनाने की कोशिश करने की तुलना में विभिन्न घटकों से व्यवसाय-डोमेन क्लासेस एं बनाना अधिक स्वाभाविक है। उदाहरण के लिए, एक त्वरक पेडल और एक स्टीयरिंग व्हील बहुत कम सामान्य गुण (कंप्यूटर प्रोग्रामिंग) साझा करते हैं, फिर भी दोनों एक कार में महत्वपूर्ण घटक हैं। वे क्या कर सकते हैं और कार को लाभ पहुंचाने के लिए उनका उपयोग कैसे किया जा सकता है, इसे आसानी से परिभाषित किया जा सकता है। संरचना लंबी अवधि में एक अधिक स्थिर व्यवसाय डोमेन भी प्रदान करती है क्योंकि यह परिवार के सदस्यों की विचित्रताओं से कम प्रभावित होती है। दूसरे शब्दों में, यह रचना करना बहुत अच्छा है कि कोई वस्तु क्या कर सकती है (है-ए) जो वह है (है-ए) का विस्तार करने के अतिरिक्त ।<ref name="FHDPs">{{cite book | |||
| last1 = Freeman | | last1 = Freeman | ||
| first1 = Eric | | first1 = Eric | ||
| Line 230: | Line 228: | ||
| isbn = 978-0-596-00712-6 | | isbn = 978-0-596-00712-6 | ||
}}</ref> | }}</ref> | ||
विरासत के माध्यम से व्यवसाय-डोमेन | विरासत के माध्यम से व्यवसाय-डोमेन क्लासेस के बीच व्यवहार वितरित करने के लिए एक पदानुक्रमित संबंध बनाने के अतिरिक्त भिन्न -भिन्न इंटरफेस में सिस्टम ऑब्जेक्ट व्यवहार की पहचान करके प्रारंभिक डिजाइन को सरल बनाया गया है। यह दृष्टिकोण भविष्य की आवश्यकताओं के परिवर्तनों को अधिक आसानी से समायोजित करता है, अन्यथा इनहेरिटेंस मॉडल में व्यवसाय-डोमेन क्लासेस के पूर्ण पुनर्गठन की आवश्यकता होगी। इसके अतिरिक्त, यह विरासत-आधारित मॉडल में अपेक्षाकृत मामूली परिवर्तनों से जुड़ी समस्याओं से बचा जाता है जिसमें क्लासेस की कई पीढ़ियाँ सम्मलित होती हैं। | ||
रचना संबंध अधिक लचीला है क्योंकि इसे रनटाइम पर बदला जा सकता है, जबकि उप-टाइपिंग संबंध स्थिर होते हैं और कई भाषाओं में पुनर्संकलन की आवश्यकता होती है। | रचना संबंध अधिक लचीला है क्योंकि इसे रनटाइम पर बदला जा सकता है, जबकि उप-टाइपिंग संबंध स्थिर होते हैं और कई भाषाओं में पुनर्संकलन की आवश्यकता होती है। | ||
| Line 236: | Line 234: | ||
== कमियां == | == कमियां == | ||
इनहेरिटेंस के अतिरिक्त संरचना का उपयोग करने का एक सामान्य दोष यह है कि भिन्न -भिन्न घटकों द्वारा प्रदान की जाने वाली विधियों को व्युत्पन्न प्रकार में लागू करना पड़ सकता है, यदि वे केवल [[अग्रेषण (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग)]] हों (यह अधिकांश प्रोग्रामिंग भाषाओं में सच है, लेकिन नहीं सब; देखें {{section link|#Avoiding drawbacks}}). इसके विपरीत, इनहेरिटेंस के लिए व्युत्पन्न क्लास के भीतर आधार क्लास के सभी विधियो को फिर से लागू करने की आवश्यकता नहीं होती है। अपितु , व्युत्पन्न क्लास को केवल आधार क्लास विधियों की तुलना में भिन्न व्यवहार वाले विधियो को लागू (ओवरराइड) करने की आवश्यकता है। यदि बेस क्लास में डिफ़ॉल्ट व्यवहार प्रदान करने वाली कई विधियाँ हैं और उनमें से केवल कुछ को व्युत्पन्न क्लास के भीतर ओवरराइड करने की आवश्यकता है, तो इसके लिए अधिक कम प्रोग्रामिंग प्रयास की आवश्यकता हो सकती है। | |||
उदाहरण के लिए, नीचे दिए गए सी # कोड में, वेरिएबल्स और विधियों के {{code|Employee}} बेस क्लास द्वारा विरासत में मिला है {{code|HourlyEmployee}} और {{code|SalariedEmployee}} व्युत्पन्न | उदाहरण के लिए, नीचे दिए गए सी # कोड में, वेरिएबल्स और विधियों के {{code|Employee}} बेस क्लास द्वारा विरासत में मिला है {{code|HourlyEmployee}} और {{code|SalariedEmployee}} व्युत्पन्न उपक्लास । केवल {{code|Pay()}} विधि को प्रत्येक व्युत्पन्न उपक्लास द्वारा कार्यान्वित (विशेष) करने की आवश्यकता है। अन्य विधियों को आधार क्लास द्वारा ही लागू किया जाता है, और इसके सभी व्युत्पन्न उपक्लासेस द्वारा साझा किया जाता है; उन्हें फिर से लागू करने (ओवरराइड) या यहां तक कि उपक्लास परिभाषाओं में उल्लेख करने की आवश्यकता नहीं है। | ||
<वाक्यविन्यास प्रकाश लैंग = csharp> | <वाक्यविन्यास प्रकाश लैंग = csharp> | ||
// बेस क्लास | // बेस क्लास | ||
सार्वजनिक सार | सार्वजनिक सार क्लास कर्मचारी | ||
{ | { | ||
// गुण | // गुण | ||
| Line 254: | Line 252: | ||
} | } | ||
// व्युत्पन्न | // व्युत्पन्न उपक्लास | ||
पब्लिक क्लास प्रति घंटा कर्मचारी: कर्मचारी | पब्लिक क्लास प्रति घंटा कर्मचारी: कर्मचारी | ||
{ | { | ||
| Line 265: | Line 263: | ||
} | } | ||
// व्युत्पन्न | // व्युत्पन्न उपक्लास | ||
सार्वजनिक | सार्वजनिक क्लास के वेतनभोगी कर्मचारी: कर्मचारी | ||
{ | { | ||
// वर्तमान वेतन अवधि के लिए भुगतान प्राप्त करें | // वर्तमान वेतन अवधि के लिए भुगतान प्राप्त करें | ||
Revision as of 22:26, 20 February 2023
 | This article uses bare URLs, which are uninformative and vulnerable to link rot. (August 2022) (Learn how and when to remove this template message) |
 | This article may be confusing or unclear to readers. (October 2015) (Learn how and when to remove this template message) |
ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग ऊप में इनहेरिटेंस पर रचना सिद्धांत या सम्मिश्र पुनः प्रयोग सिद्धांत के रूप में होता है तथा क्लासेस को बहुरूपता कंप्यूटर विज्ञान व्यवहार और कोड का पुन: उपयोग करना चाहिए तथा उनकी संरचना द्वारा अन्य क्लासेस के उदाहरण देना चाहिए जो किसी आधार या पैरेंट क्लास से प्राप्त इनहेरिटेंस कंप्यूटर विज्ञान के अतिरिक्त वांछित कार्यकार्यात्मकता को कार्यान्वित करते हैं।[2] यह ऊप का प्रायः सिद्धांत है, जिसमे कि प्रभावशाली पुस्तक डिजाइन पैटर्न्स 1994 में हुआ था।[3]
मूल बातें
इनहेरिटेंस पर रचना का कार्यान्वयन सामान्यतः विभिन्न इंटरफ़ेस (कंप्यूटिंग) के निर्माण के साथ प्रारंभ होता है # ऑब्जेक्ट-ओरिएंटेड भाषाओं में उन व्यवहारों का प्रतिनिधित्व करता है जिन्हें सिस्टम को प्रदर्शित करना चाहिए। इंटरफेस बहुरूपता (कंप्यूटर विज्ञान) व्यवहार को सुविधाजनक बना सकते हैं। पहचाने गए इंटरफेस को लागू करने वाली क्लासेस एं आवश्यकतानुसार व्यावसायिक डोमेन क्लासेस में बनाई और जोड़ी जाती हैं। इस प्रकार, सिस्टम व्यवहार विरासत के बिना अनुभव किए जाते हैं।
वास्तव में, व्यावसायिक डोमेन क्लास बिना किसी इनहेरिटेंस के आधार क्लास हो सकते हैं। सिस्टम व्यवहारों का वैकल्पिक कार्यान्वयन एक अन्य क्लास प्रदान करके पूरा किया जाता है जो वांछित व्यवहार इंटरफ़ेस को लागू करता है। एक क्लास जिसमें एक इंटरफ़ेस का संदर्भ होता है, इंटरफ़ेस के कार्यान्वयन का समर्थन कर सकता है - एक विकल्प जिसे रनटाइम (कार्यक्रम जीवनचक्र चरण) तक विलंबित किया जा सकता है।
उदाहरण
विरासत
सी ++ में एक उदाहरण इस प्रकार है:
<वाक्यविन्यास लैंग = सीपीपी> क्लास वस्तु { जनता:
आभासी शून्य अद्यतन () {
// नो-ऑप
}
आभासी शून्य ड्रा () {
// नो-ऑप
}
आभासी शून्य टक्कर (ऑब्जेक्ट ऑब्जेक्ट्स []) {
// नो-ऑप
}
};
क्लास दृश्यमान: सार्वजनिक वस्तु {
मॉडल * मॉडल;
जनता:
आभासी शून्य ड्रा () ओवरराइड {
// कोड इस वस्तु की स्थिति पर एक मॉडल बनाने के लिए
}
};
क्लास सॉलिड: पब्लिक ऑब्जेक्ट { जनता:
आभासी शून्य टक्कर (ऑब्जेक्ट ऑब्जेक्ट्स []) ओवरराइड {
// अन्य वस्तुओं के साथ टकराव की जांच करने और प्रतिक्रिया करने के लिए कोड
}
};
जंगम क्लास : सार्वजनिक वस्तु { जनता:
आभासी शून्य अद्यतन () ओवरराइड {
// कोड इस वस्तु की स्थिति को अद्यतन करने के लिए
}
}; </वाक्यविन्यास हाइलाइट>
फिर, मान लीजिए कि हमारे पास ये ठोस क्लास भी हैं:
- क्लासेस
Player- जो हैSolid,MovableऔरVisible - क्लासेस
Cloud- जो हैMovableऔरVisible, लेकिन नहींSolid - क्लासेस
Building- जो हैSolidऔरVisible, लेकिन नहींMovable - क्लासेस
Trap- जो हैSolid, लेकिन नहींVisibleऔर नMovable
ध्यान दें कि मल्टीपल इनहेरिटेंस खतरनाक है यदि सावधानी से लागू नहीं किया गया है क्योंकि इससे मल्टीपल इनहेरिटेंस#द डायमंड प्रॉब्लम हो सकती है। इसका एक समाधान इस प्रकार की क्लासेस एं बनाना है VisibleAndSolid, VisibleAndMovable, VisibleAndSolidAndMovable, आदि हर आवश्यक संयोजन के लिए; चूंकि , यह बड़ी मात्रा में दोहराव वाले कोड की ओर ले जाता है। C ++ मल्टीपल इनहेरिटेंस की डायमंड प्रॉब्लम को हल करने के लिए आभासी विरासत का उपयोग करता है।
संरचना और इंटरफेस
इस खंड में सी ++ उदाहरण कोड पुन: उपयोग और बहुरूपता प्राप्त करने के लिए संरचना और इंटरफेस का उपयोग करने के सिद्धांत को प्रदर्शित करता है। सी ++ भाषा में इंटरफेस घोषित करने के लिए एक समर्पित कीवर्ड नहीं होने के कारण, निम्न सी ++ उदाहरण शुद्ध सार आधार क्लास से विरासत का उपयोग करता है। अधिकांश उद्देश्यों के लिए, यह कार्यात्मक रूप से जावा और सी # जैसी अन्य भाषाओं में प्रदान किए गए इंटरफेस के बराबर है।
नामक एक अमूर्त क्लास का परिचय दें VisibilityDelegate, उपक्लासेस के साथ NotVisible और Visible, जो किसी वस्तु को खींचने का साधन प्रदान करता है:
<वाक्यविन्यास लैंग = सीपीपी> क्लास दृश्यता प्रतिनिधि { जनता:
आभासी शून्य ड्रा () = 0;
};
क्लास नॉटविजिबल: पब्लिक विजिबिलिटी डेलिगेट { जनता:
आभासी शून्य ड्रा () ओवरराइड {
// नो-ऑप
}
};
क्लास दृश्यमान: सार्वजनिक दृश्यता प्रतिनिधि { जनता:
आभासी शून्य ड्रा () ओवरराइड {
// कोड इस वस्तु की स्थिति पर एक मॉडल बनाने के लिए
}
}; </वाक्यविन्यास हाइलाइट>
नामक एक अमूर्त क्लास का परिचय दें UpdateDelegate, उपक्लासेस के साथ NotMovable और Movable, जो किसी वस्तु को स्थानांतरित करने का साधन प्रदान करता है:
<वाक्यविन्यास लैंग = सीपीपी> क्लास अद्यतन प्रतिनिधि { जनता:
आभासी शून्य अद्यतन () = 0;
};
क्लास नॉटमूवेबल: पब्लिक अपडेटडिलेगेट { जनता:
आभासी शून्य अद्यतन () ओवरराइड {
// नो-ऑप
}
};
क्लास मूवेबल: पब्लिक अपडेटडिलेगेट { जनता:
आभासी शून्य अद्यतन () ओवरराइड {
// कोड इस वस्तु की स्थिति को अद्यतन करने के लिए
}
}; </वाक्यविन्यास हाइलाइट>
नामक एक अमूर्त क्लास का परिचय दें CollisionDelegate, उपक्लासेस के साथ NotSolid और Solid, जो किसी वस्तु से टकराने का साधन प्रदान करता है:
<वाक्यविन्यास लैंग = सीपीपी> क्लास टकराव प्रतिनिधि { जनता:
आभासी शून्य टक्कर (ऑब्जेक्ट ऑब्जेक्ट्स []) = 0;
};
क्लास नॉटसॉलिड: पब्लिक कोलिशनडिलेगेट { जनता:
आभासी शून्य टक्कर (ऑब्जेक्ट ऑब्जेक्ट्स []) ओवरराइड {
// नो-ऑप
}
};
क्लास सॉलिड: पब्लिक कोलिशनडिलेगेट { जनता:
आभासी शून्य टक्कर (ऑब्जेक्ट ऑब्जेक्ट्स []) ओवरराइड {
// अन्य वस्तुओं के साथ टकराव की जांच करने और प्रतिक्रिया करने के लिए कोड
}
}; </वाक्यविन्यास हाइलाइट>
अंत में, नाम की एक क्लासेस का परिचय दें Object इसकी दृश्यता को नियंत्रित करने के लिए सदस्यों के साथ (ए VisibilityDelegate), चलनशीलता (एक का उपयोग करके UpdateDelegate), और दृढ़ता (ए का उपयोग करके CollisionDelegate). इस क्लास में ऐसी विधियाँ हैं जो इसके सदस्यों को सौंपती हैं, उदा। update() बस पर एक विधि कहते हैं UpdateDelegate:
<वाक्यविन्यास लैंग = सीपीपी> क्लास वस्तु {
दृश्यता प्रतिनिधि* _v; UpdateDelegate* _u; CollisionDelegate* _c;
जनता:
ऑब्जेक्ट (दृश्यता प्रतिनिधि * v, अद्यतन प्रतिनिधि * यू, टकराव प्रतिनिधि * सी)
: _वी (वी)
, _तुम तुम)
, _सी (सी)
{}
शून्य अद्यतन () {
_यू-> अपडेट ();
}
शून्य ड्रा () {
_v-> ड्रा ();
}
शून्य टक्कर (ऑब्जेक्ट ऑब्जेक्ट्स []) {
_c-> टकराना (ऑब्जेक्ट्स);
}
}; </वाक्यविन्यास हाइलाइट>
फिर, ठोस क्लासेस एं दिखेंगी:
<वाक्यविन्यास लैंग = सीपीपी> क्लास प्लेयर: पब्लिक ऑब्जेक्ट { जनता:
खिलाड़ी ()
: ऑब्जेक्ट (नया दृश्यमान (), नया चल (), नया ठोस ())
{}
// ...
};
क्लास धुआँ: सार्वजनिक वस्तु { जनता:
धुआँ()
: ऑब्जेक्ट (नया दृश्यमान (), नया मूवेबल (), नया नॉटसॉलिड ())
{}
// ...
}; </वाक्यविन्यास हाइलाइट>
लाभ
इनहेरिटेंस पर रचना का पक्ष लेना एक डिज़ाइन सिद्धांत है जो डिज़ाइन को उच्च लचीलापन देता है। उनके बीच समानता खोजने और पारिवारिक पेड़ बनाने की कोशिश करने की तुलना में विभिन्न घटकों से व्यवसाय-डोमेन क्लासेस एं बनाना अधिक स्वाभाविक है। उदाहरण के लिए, एक त्वरक पेडल और एक स्टीयरिंग व्हील बहुत कम सामान्य गुण (कंप्यूटर प्रोग्रामिंग) साझा करते हैं, फिर भी दोनों एक कार में महत्वपूर्ण घटक हैं। वे क्या कर सकते हैं और कार को लाभ पहुंचाने के लिए उनका उपयोग कैसे किया जा सकता है, इसे आसानी से परिभाषित किया जा सकता है। संरचना लंबी अवधि में एक अधिक स्थिर व्यवसाय डोमेन भी प्रदान करती है क्योंकि यह परिवार के सदस्यों की विचित्रताओं से कम प्रभावित होती है। दूसरे शब्दों में, यह रचना करना बहुत अच्छा है कि कोई वस्तु क्या कर सकती है (है-ए) जो वह है (है-ए) का विस्तार करने के अतिरिक्त ।[1] विरासत के माध्यम से व्यवसाय-डोमेन क्लासेस के बीच व्यवहार वितरित करने के लिए एक पदानुक्रमित संबंध बनाने के अतिरिक्त भिन्न -भिन्न इंटरफेस में सिस्टम ऑब्जेक्ट व्यवहार की पहचान करके प्रारंभिक डिजाइन को सरल बनाया गया है। यह दृष्टिकोण भविष्य की आवश्यकताओं के परिवर्तनों को अधिक आसानी से समायोजित करता है, अन्यथा इनहेरिटेंस मॉडल में व्यवसाय-डोमेन क्लासेस के पूर्ण पुनर्गठन की आवश्यकता होगी। इसके अतिरिक्त, यह विरासत-आधारित मॉडल में अपेक्षाकृत मामूली परिवर्तनों से जुड़ी समस्याओं से बचा जाता है जिसमें क्लासेस की कई पीढ़ियाँ सम्मलित होती हैं। रचना संबंध अधिक लचीला है क्योंकि इसे रनटाइम पर बदला जा सकता है, जबकि उप-टाइपिंग संबंध स्थिर होते हैं और कई भाषाओं में पुनर्संकलन की आवश्यकता होती है।
कुछ भाषाएँ, विशेष रूप से गो (प्रोग्रामिंग भाषा)[4] और जंग (प्रोग्रामिंग भाषा),[5] विशेष रूप से प्रकार की रचना का उपयोग करें।
कमियां
इनहेरिटेंस के अतिरिक्त संरचना का उपयोग करने का एक सामान्य दोष यह है कि भिन्न -भिन्न घटकों द्वारा प्रदान की जाने वाली विधियों को व्युत्पन्न प्रकार में लागू करना पड़ सकता है, यदि वे केवल अग्रेषण (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग) हों (यह अधिकांश प्रोग्रामिंग भाषाओं में सच है, लेकिन नहीं सब; देखें § Avoiding drawbacks). इसके विपरीत, इनहेरिटेंस के लिए व्युत्पन्न क्लास के भीतर आधार क्लास के सभी विधियो को फिर से लागू करने की आवश्यकता नहीं होती है। अपितु , व्युत्पन्न क्लास को केवल आधार क्लास विधियों की तुलना में भिन्न व्यवहार वाले विधियो को लागू (ओवरराइड) करने की आवश्यकता है। यदि बेस क्लास में डिफ़ॉल्ट व्यवहार प्रदान करने वाली कई विधियाँ हैं और उनमें से केवल कुछ को व्युत्पन्न क्लास के भीतर ओवरराइड करने की आवश्यकता है, तो इसके लिए अधिक कम प्रोग्रामिंग प्रयास की आवश्यकता हो सकती है।
उदाहरण के लिए, नीचे दिए गए सी # कोड में, वेरिएबल्स और विधियों के Employee बेस क्लास द्वारा विरासत में मिला है HourlyEmployee और SalariedEmployee व्युत्पन्न उपक्लास । केवल Pay() विधि को प्रत्येक व्युत्पन्न उपक्लास द्वारा कार्यान्वित (विशेष) करने की आवश्यकता है। अन्य विधियों को आधार क्लास द्वारा ही लागू किया जाता है, और इसके सभी व्युत्पन्न उपक्लासेस द्वारा साझा किया जाता है; उन्हें फिर से लागू करने (ओवरराइड) या यहां तक कि उपक्लास परिभाषाओं में उल्लेख करने की आवश्यकता नहीं है।
<वाक्यविन्यास प्रकाश लैंग = csharp> // बेस क्लास सार्वजनिक सार क्लास कर्मचारी {
// गुण
संरक्षित स्ट्रिंग नाम {प्राप्त करें; तय करना; }
संरक्षित इंट आईडी {प्राप्त करें; तय करना; }
संरक्षित दशमलव भुगतान दर {प्राप्त करें; तय करना; }
संरक्षित int घंटे काम किया { प्राप्त करें; }
// वर्तमान वेतन अवधि के लिए भुगतान प्राप्त करें सार्वजनिक सार दशमलव वेतन ();
}
// व्युत्पन्न उपक्लास पब्लिक क्लास प्रति घंटा कर्मचारी: कर्मचारी {
// वर्तमान वेतन अवधि के लिए भुगतान प्राप्त करें
सार्वजनिक ओवरराइड दशमलव वेतन ()
{
// काम किया गया समय घंटों में है
वापसी के घंटे काम * वेतन दर;
}
}
// व्युत्पन्न उपक्लास सार्वजनिक क्लास के वेतनभोगी कर्मचारी: कर्मचारी {
// वर्तमान वेतन अवधि के लिए भुगतान प्राप्त करें
सार्वजनिक ओवरराइड दशमलव वेतन ()
{
// वेतन दर प्रति घंटे की दर के अतिरिक्त वार्षिक वेतन है
वापसी के घंटे काम * वेतन दर / 2087;
}
} </वाक्यविन्यास हाइलाइट>
कमियों से बचना
ट्रेट्स (कंप्यूटर साइंस), mixin्स, (टाइप) एम्बेडिंग, या प्रोटोकॉल (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग) एक्सटेंशन का उपयोग करके इस कमी से बचा जा सकता है।
कुछ भाषाएँ इसे कम करने के लिए विशिष्ट साधन प्रदान करती हैं:
- सी शार्प (प्रोग्रामिंग लैंग्वेज) | सी # संस्करण 8.0 के बाद से डिफ़ॉल्ट इंटरफ़ेस विधि प्रदान करता है जो शरीर को इंटरफ़ेस सदस्य को परिभाषित करने की अनुमति देता है।[6]
- डी (प्रोग्रामिंग भाषा) एक स्पष्ट उपनाम प्रदान करता है, यह घोषणा एक प्रकार के भीतर हर विधि और किसी अन्य निहित प्रकार के सदस्य को अग्रेषित कर सकती है।[7]
- डार्ट (प्रोग्रामिंग भाषा) डिफ़ॉल्ट कार्यान्वयन के साथ मिक्सिन प्रदान करता है जिसे साझा किया जा सकता है।
- गो (प्रोग्रामिंग लैंग्वेज) टाइप एम्बेडिंग अग्रेषण विधियों की आवश्यकता से बचाती है।[8]
- जावा (प्रोग्रामिंग भाषा) संस्करण 8 के बाद से डिफ़ॉल्ट इंटरफ़ेस विधियाँ प्रदान करता है। प्रोजेक्ट लोम्बोक[9] प्रतिनिधिमंडल का समर्थन करता है
@Delegateप्रत्यायोजित क्षेत्र से सभी विधियों के नामों और प्रकारों को कॉपी करने और बनाए रखने के अतिरिक्त क्षेत्र पर एनोटेशन।[10] * जूलिया (प्रोग्रामिंग भाषा) मैक्रोज़ का उपयोग अग्रेषण विधियों को उत्पन्न करने के लिए किया जा सकता है। Lazy.jl जैसे कई कार्यान्वयन सम्मलित हैं[11] और TypedDelegation.jl।[12][13] - कोटलिन (प्रोग्रामिंग भाषा) में लैंग्वेज सिंटैक्स में डेलिगेशन पैटर्न सम्मलित है।[14]
- PHP लक्षणों (कंप्यूटर विज्ञान) का समर्थन करता है।
- राकू (प्रोग्रामिंग भाषा) एक प्रदान करता है
handlesविधि अग्रेषण की सुविधा के लिए विशेषता।[15] - रस्ट (प्रोग्रामिंग लैंग्वेज) डिफ़ॉल्ट कार्यान्वयन के साथ लक्षण प्रदान करता है।
- स्काला (प्रोग्रामिंग भाषा) (संस्करण 3 के बाद से) किसी वस्तु के चयनित सदस्यों के लिए उपनामों को परिभाषित करने के लिए एक निर्यात खंड प्रदान करता है।[16]
- स्विफ्ट (प्रोग्रामिंग भाषा) एक्सटेंशन का उपयोग किसी प्रोटोकॉल के डिफ़ॉल्ट कार्यान्वयन को परिभाषित करने के लिए किया जा सकता है, बजाय किसी व्यक्तिगत प्रकार के कार्यान्वयन के।[17]
अनुभवजन्य अध्ययन
2013 में 93 ओपन सोर्स जावा प्रोग्राम (भिन्न -भिन्न आकार के) के एक अध्ययन में पाया गया कि:
While there is not huge opportunity to replace inheritance with composition (...), the opportunity is significant (median of 2% of uses [of inheritance] are only internal reuse, and a further 22% are only external or internal reuse). Our results suggest there is no need for concern regarding abuse of inheritance (at least in open-source Java software), but they do highlight the question regarding use of composition versus inheritance. If there are significant costs associated with using inheritance when composition could be used, then our results suggest there is some cause for concern.
— Tempero et al., "What programmers do with inheritance in Java"[18]
यह भी देखें
- प्रतिनिधिमंडल पैटर्न
- लिस्कोव प्रतिस्थापन सिद्धांत
- वस्तु उन्मुख डिजाइन
- वस्तु रचना
- भूमिका-उन्मुख प्रोग्रामिंग
- राज्य पैटर्न
- रणनीति पैटर्न
संदर्भ
- ↑ 1.0 1.1 Freeman, Eric; Robson, Elisabeth; Sierra, Kathy; Bates, Bert (2004). Head First Design Patterns. O'Reilly. p. 23. ISBN 978-0-596-00712-6.
- ↑ Knoernschild, Kirk (2002). Java Design - Objects, UML, and Process: 1.1.5 Composite Reuse Principle (CRP). Addison-Wesley Inc. ISBN 9780201750447. Retrieved 2012-05-29.
- ↑ Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. p. 20. ISBN 0-201-63361-2. OCLC 31171684.
- ↑ Pike, Rob (2012-06-25). "Less is exponentially more". Retrieved 2016-10-01.
- ↑ "Characteristics of Object-Oriented Languages - The Rust Programming Language". doc.rust-lang.org. Retrieved 2022-10-10.
- ↑ "What's new in C# 8.0". Microsoft Docs. Microsoft. Retrieved 2019-02-20.
- ↑ "Alias This". D Language Reference. Retrieved 2019-06-15.
- ↑ "(Type) Embedding". The Go Programming Language Documentation. Retrieved 2019-05-10.
- ↑ https://projectlombok.org
- ↑ "@Delegate". Project Lombok. Retrieved 2018-07-11.
- ↑ https://github.com/MikeInnes/Lazy.jl
- ↑ https://github.com/JeffreySarnoff/TypedDelegation.jl
- ↑ "Method forwarding macro". JuliaLang (in English). 20 April 2019. Retrieved 18 August 2022.
- ↑ "Delegated Properties". Kotlin Reference. JetBrains. Retrieved 2018-07-11.
- ↑ "Type system". docs.raku.org. Retrieved 18 August 2022.
- ↑ "Export Clauses". Scala Documentation. Retrieved 2021-10-06.
- ↑ "Protocols". The Swift Programming Language. Apple Inc. Retrieved 2018-07-11.
- ↑ Tempero, Ewan; Yang, Hong Yul; Noble, James (2013). "What programmers do with inheritance in Java" (PDF). ECOOP 2013 – Object-Oriented Programming. ECOOP 2013–Object-Oriented Programming. Lecture Notes in Computer Science. Vol. 7920. pp. 577–601. doi:10.1007/978-3-642-39038-8_24. ISBN 978-3-642-39038-8.
