GRASP (वस्तु-उन्मुख डिज़ाइन): Difference between revisions
(Created page with "{{short description|Guidelines in object-oriented design}} {{more footnotes|date=May 2015}} {{primary|date=May 2015}} सामान्य उत्तरदायित्...") |
No edit summary |
||
| Line 1: | Line 1: | ||
{{short description|Guidelines in object-oriented design}} | {{short description|Guidelines in object-oriented design}}सामान्य उत्तरदायित्व असाइनमेंट सॉफ़्टवेयर पैटर्न (या सिद्धांत), संक्षिप्त रूप से जीआरएएसपी, [[वस्तु-उन्मुख डिज़ाइन|"ऑब्जेक्ट-अभिविन्यस्त डिज़ाइन]] और उत्तरदायित्व असाइनमेंट में नौ मूलभूत सिद्धांतों" का एक समूह है<ref name="Larman2001"/>{{rp|6}} जिसमे पहली बार [[क्रेग लर्मन]] ने अपनी 1997 की पुस्तक एप्लाइंग यूएमएल एंड पैटर्न्स में प्रकाशित किया था। | ||
{{ | |||
जीआरएएसपी में उपयोग किए जाने वाले विभिन्न पैटर्न और सिद्धांत नियंत्रक, निर्माता, अप्रत्यक्ष, सूचना विशेषज्ञ, कम [[युग्मन (कंप्यूटर विज्ञान)]], उच्च [[सामंजस्य (कंप्यूटर विज्ञान)]], [[बहुरूपता (वस्तु-उन्मुख प्रोग्रामिंग)|बहुरूपता (ऑब्जेक्ट-अभिविन्यस्त प्रोग्रामिंग)]], संरक्षित विविधताएं और शुद्ध निर्माण हैं।<ref name="Umair2018"/>ये सभी पैटर्न कई सॉफ्टवेयर विकास परियोजनाओं में आम तौर पर होने वाली कुछ सॉफ्टवेयर समस्याओं को हल करते हैं। इन तकनीकों का आविष्कार काम करने के नए तरीके बनाने के लिए नहीं किया गया है, बल्कि ऑब्जेक्ट-ओरिएंटेड डिज़ाइन में पुराने, आज़माए और परीक्षण किए गए [[कंप्यूटर प्रोग्रामिंग]] सिद्धांतों को बेहतर दस्तावेज़ और मानकीकृत करने के लिए किया गया है। | |||
क्रेग लार्मन का कहना है कि [[सॉफ़्टवेयर]] विकास के लिए महत्वपूर्ण डिज़ाइन टूल डिज़ाइन सिद्धांतों में अच्छी तरह से शिक्षित दिमाग है। यह [[एकीकृत मॉडलिंग भाषा]] या कोई अन्य तकनीक नहीं है।<ref name="Larman2004"/>{{rp|272}} इस प्रकार, जीआरएएसपी सिद्धांत वास्तव में एक मानसिक टूलसमूह हैं, जो ऑब्जेक्ट-ओरिएंटेड सॉफ़्टवेयर के डिज़ाइन में मदद करने के लिए एक शिक्षण सहायता है। | |||
क्रेग लार्मन का कहना है कि [[सॉफ़्टवेयर]] विकास के लिए महत्वपूर्ण डिज़ाइन टूल डिज़ाइन सिद्धांतों में अच्छी तरह से शिक्षित दिमाग है। यह [[एकीकृत मॉडलिंग भाषा]] या कोई अन्य तकनीक नहीं है।<ref name="Larman2004"/>{{rp|272}} इस प्रकार, | |||
==पैटर्न== | ==पैटर्न== | ||
ऑब्जेक्ट-ओरिएंटेड डिज़ाइन में, एक पैटर्न किसी समस्या और समाधान का नामित विवरण होता है जिसे नए संदर्भों में लागू किया जा सकता है; आदर्श रूप से, एक पैटर्न हमें सलाह देता है कि अलग-अलग परिस्थितियों में इसके समाधान को कैसे लागू किया जाए और ताकतों और व्यापार-बंदों पर विचार किया जाए। कई पैटर्न, समस्या की एक विशिष्ट श्रेणी को देखते हुए, | ऑब्जेक्ट-ओरिएंटेड डिज़ाइन में, एक पैटर्न किसी समस्या और समाधान का नामित विवरण होता है जिसे नए संदर्भों में लागू किया जा सकता है; आदर्श रूप से, एक पैटर्न हमें सलाह देता है कि अलग-अलग परिस्थितियों में इसके समाधान को कैसे लागू किया जाए और ताकतों और व्यापार-बंदों पर विचार किया जाए। कई पैटर्न, समस्या की एक विशिष्ट श्रेणी को देखते हुए, ऑब्जेक्ट को जिम्मेदारियों के असाइनमेंट का मार्गदर्शन करते हैं। | ||
===सूचना विशेषज्ञ=== | ===सूचना विशेषज्ञ=== | ||
{{see also|Information hiding}} | {{see also|Information hiding}} | ||
समस्या: एक बुनियादी सिद्धांत क्या है जिसके द्वारा | समस्या: एक बुनियादी सिद्धांत क्या है जिसके द्वारा ऑब्जेक्ट को जिम्मेदारियाँ सौंपी जाती हैं?<br> | ||
समाधान: उस वर्ग को जिम्मेदारी सौंपें जिसके पास इसे पूरा करने के लिए आवश्यक जानकारी है। | समाधान: उस वर्ग को जिम्मेदारी सौंपें जिसके पास इसे पूरा करने के लिए आवश्यक जानकारी है। | ||
| Line 28: | Line 24: | ||
===निर्माता=== | ===निर्माता=== | ||
{{see also|Factory pattern}} | {{see also|Factory pattern}} | ||
ऑब्जेक्ट का निर्माण किसी ऑब्जेक्ट-अभिविन्यस्त प्रणाली में सबसे आम गतिविधियों में से एक है। ऑब्जेक्ट के निर्माण के लिए कौन सा वर्ग जिम्मेदार है, यह विशेष वर्गों की ऑब्जेक्ट के बीच संबंध की एक मौलिक संपत्ति है। | |||
समस्या: | समस्या: ऑब्जेक्ट कौन बनाता है <code>A</code>?<br> | ||
समाधान: सामान्य तौर पर, कक्षा निर्दिष्ट करें <code>B</code> | समाधान: सामान्य तौर पर, कक्षा निर्दिष्ट करें <code>B</code> ऑब्जेक्ट बनाने की जिम्मेदारी <code>A</code> यदि निम्नलिखित में से एक, या अधिमानतः अधिक, लागू हो: | ||
* के उदाहरण <code>B</code> के उदाहरणों को शामिल करना या समग्र रूप से एकत्रित करना <code>A</code> | * के उदाहरण <code>B</code> के उदाहरणों को शामिल करना या समग्र रूप से एकत्रित करना <code>A</code> | ||
* के उदाहरण <code>B</code> के उदाहरण रिकॉर्ड करें <code>A</code> | * के उदाहरण <code>B</code> के उदाहरण रिकॉर्ड करें <code>A</code> | ||
| Line 44: | Line 40: | ||
समस्या: इनपुट सिस्टम इवेंट को संभालने के लिए कौन जिम्मेदार होना चाहिए?<br> | समस्या: इनपुट सिस्टम इवेंट को संभालने के लिए कौन जिम्मेदार होना चाहिए?<br> | ||
समाधान: एक ''उपयोग मामले नियंत्रक'' का उपयोग किसी उपयोग मामले की ''सभी'' सिस्टम घटनाओं से निपटने के लिए किया जाना चाहिए, और इसका उपयोग एक से अधिक उपयोग मामलों के लिए किया जा सकता है। [[उदाहरण]] के लिए, ''उपयोगकर्ता बनाएं'' और ''उपयोगकर्ता हटाएं'' उपयोग मामलों के लिए, दो अलग-अलग उपयोग मामले नियंत्रकों के बजाय, ''उपयोगकर्ता नियंत्रक'' नामक एक एकल वर्ग हो सकता है। वैकल्पिक रूप से एक ''मुखौटा नियंत्रक'' का उपयोग किया जाएगा; यह तब लागू होता है जब घटना को संभालने की जिम्मेदारी वाली | समाधान: एक ''उपयोग मामले नियंत्रक'' का उपयोग किसी उपयोग मामले की ''सभी'' सिस्टम घटनाओं से निपटने के लिए किया जाना चाहिए, और इसका उपयोग एक से अधिक उपयोग मामलों के लिए किया जा सकता है। [[उदाहरण]] के लिए, ''उपयोगकर्ता बनाएं'' और ''उपयोगकर्ता हटाएं'' उपयोग मामलों के लिए, दो अलग-अलग उपयोग मामले नियंत्रकों के बजाय, ''उपयोगकर्ता नियंत्रक'' नामक एक एकल वर्ग हो सकता है। वैकल्पिक रूप से एक ''मुखौटा नियंत्रक'' का उपयोग किया जाएगा; यह तब लागू होता है जब घटना को संभालने की जिम्मेदारी वाली ऑब्जेक्ट समग्र प्रणाली या मूल ऑब्जेक्ट का प्रतिनिधित्व करती है। | ||
नियंत्रक को यूआई परत से परे पहली | नियंत्रक को यूआई परत से परे पहली ऑब्जेक्ट के रूप में परिभाषित किया गया है जो सिस्टम ऑपरेशन को प्राप्त करता है और समन्वयित (नियंत्रित) करता है। नियंत्रक को उस कार्य को अन्य ऑब्जेक्ट को सौंपना चाहिए जिसे करने की आवश्यकता है; यह गतिविधि का समन्वय या नियंत्रण करता है। इसे खुद ज्यादा काम नहीं करना चाहिए. जीआरएएसपी नियंत्रक को एप्लिकेशन/सेवा परत का एक हिस्सा माना जा सकता है<ref name="Yahoo"/>(यह मानते हुए कि एप्लिकेशन ने एक सूचना प्रणाली तार्किक वास्तुकला में सामान्य परतों के साथ ऑब्जेक्ट-ओरिएंटेड सिस्टम में एप्लिकेशन/सेवा परत और [[डोमेन परत]] के बीच एक स्पष्ट अंतर बनाया है)। | ||
संबंधित पैटर्न या सिद्धांत: कमांड_पैटर्न, फेकाडे_पैटर्न, लेयर_(ऑब्जेक्ट-ओरिएंटेड_डिज़ाइन), शुद्ध निर्माण | संबंधित पैटर्न या सिद्धांत: कमांड_पैटर्न, फेकाडे_पैटर्न, लेयर_(ऑब्जेक्ट-ओरिएंटेड_डिज़ाइन), शुद्ध निर्माण | ||
===निर्देश=== | ===निर्देश=== | ||
अप्रत्यक्ष पैटर्न कम युग्मन का समर्थन करता है और दो तत्वों के बीच मध्यस्थता की जिम्मेदारी एक मध्यवर्ती | अप्रत्यक्ष पैटर्न कम युग्मन का समर्थन करता है और दो तत्वों के बीच मध्यस्थता की जिम्मेदारी एक मध्यवर्ती ऑब्जेक्ट को सौंपकर उनके बीच क्षमता का पुन: उपयोग करता है। इसका एक उदाहरण मॉडल-व्यू-नियंत्रक पैटर्न में डेटा (मॉडल) और उसके प्रतिनिधित्व (दृश्य) के बीच मध्यस्थता के लिए एक नियंत्रक घटक की शुरूआत है। यह सुनिश्चित करता है कि उनके बीच युग्मन कम रहे। | ||
समस्या: दो (या अधिक) चीजों के बीच सीधे जुड़ाव से बचने के लिए जिम्मेदारी कहां सौंपी जाए? | समस्या: दो (या अधिक) चीजों के बीच सीधे जुड़ाव से बचने के लिए जिम्मेदारी कहां सौंपी जाए? ऑब्जेक्ट को कैसे अलग करें ताकि कम युग्मन समर्थित हो और पुन: उपयोग की क्षमता अधिक बनी रहे? <br> | ||
समाधान: अन्य घटकों या सेवाओं के बीच मध्यस्थता करने के लिए एक मध्यवर्ती | समाधान: अन्य घटकों या सेवाओं के बीच मध्यस्थता करने के लिए एक मध्यवर्ती ऑब्जेक्ट को जिम्मेदारी सौंपें ताकि वे सीधे युग्मित न हों। <br> | ||
मध्यस्थ अन्य घटकों के बीच एक अप्रत्यक्ष संबंध बनाता है। | मध्यस्थ अन्य घटकों के बीच एक अप्रत्यक्ष संबंध बनाता है। | ||
| Line 68: | Line 65: | ||
===उच्च सामंजस्य=== | ===उच्च सामंजस्य=== | ||
{{main|Cohesion (computer science)}} | {{main|Cohesion (computer science)}} | ||
उच्च सामंजस्य एक मूल्यांकन पैटर्न है जो | उच्च सामंजस्य एक मूल्यांकन पैटर्न है जो ऑब्जेक्ट को उचित रूप से केंद्रित, प्रबंधनीय और समझने योग्य रखने का प्रयास करता है। उच्च सामंजस्य का उपयोग आम तौर पर कम युग्मन के समर्थन में किया जाता है। उच्च सामंजस्य का अर्थ है कि तत्वों के दिए गए समूह की जिम्मेदारियाँ दृढ़ता से संबंधित हैं और एक विशिष्ट विषय पर अत्यधिक केंद्रित हैं। प्रोग्रामों को वर्गों और उपप्रणालियों में तोड़ना, यदि सही ढंग से किया जाए, उन गतिविधियों का एक उदाहरण है जो नामित वर्गों और उपप्रणालियों के एकजुट गुणों को बढ़ाते हैं। वैकल्पिक रूप से, कम सामंजस्य एक ऐसी स्थिति है जिसमें तत्वों के एक समूह, उदाहरण के लिए, एक उपप्रणाली, पर बहुत अधिक असंबंधित जिम्मेदारियां होती हैं। अपने घटक तत्वों के बीच कम सामंजस्य वाले उपप्रणालियों को अक्सर समग्र रूप से समझने, पुन: उपयोग करने, बनाए रखने और बदलने में कठिनाई होती है।<ref name="Larman2004"/>{{rp|314–315}} | ||
===बहुरूपता=== | ===बहुरूपता=== | ||
| Line 75: | Line 72: | ||
समस्या: प्रकार के आधार पर विकल्पों को कैसे संभालें? प्लग करने योग्य सॉफ़्टवेयर घटक कैसे बनाएं?<br> | समस्या: प्रकार के आधार पर विकल्पों को कैसे संभालें? प्लग करने योग्य सॉफ़्टवेयर घटक कैसे बनाएं?<br> | ||
समाधान: जब संबंधित विकल्प या व्यवहार प्रकार (वर्ग) के अनुसार भिन्न होते हैं, तो व्यवहार के लिए जिम्मेदारी सौंपें - बहुरूपी संचालन का उपयोग करके - उन प्रकारों को जिनके लिए व्यवहार भिन्न होता है। (बहुरूपता के कई संबंधित अर्थ हैं। इस संदर्भ में, इसका अर्थ है विभिन्न | समाधान: जब संबंधित विकल्प या व्यवहार प्रकार (वर्ग) के अनुसार भिन्न होते हैं, तो व्यवहार के लिए जिम्मेदारी सौंपें - बहुरूपी संचालन का उपयोग करके - उन प्रकारों को जिनके लिए व्यवहार भिन्न होता है। (बहुरूपता के कई संबंधित अर्थ हैं। इस संदर्भ में, इसका अर्थ है विभिन्न ऑब्जेक्ट में सेवाओं को एक ही नाम देना।) | ||
===संरक्षित विविधताएं=== | ===संरक्षित विविधताएं=== | ||
| Line 81: | Line 78: | ||
संरक्षित विविधता पैटर्न एक [[इंटरफ़ेस (कंप्यूटर विज्ञान)]] के साथ अस्थिरता के फोकस को लपेटकर और इस इंटरफ़ेस के विभिन्न कार्यान्वयन बनाने के लिए बहुरूपता (कंप्यूटर विज्ञान) का उपयोग करके तत्वों को अन्य तत्वों (ऑब्जेक्ट्स, सिस्टम, सबसिस्टम) पर भिन्नता से बचाता है। | संरक्षित विविधता पैटर्न एक [[इंटरफ़ेस (कंप्यूटर विज्ञान)]] के साथ अस्थिरता के फोकस को लपेटकर और इस इंटरफ़ेस के विभिन्न कार्यान्वयन बनाने के लिए बहुरूपता (कंप्यूटर विज्ञान) का उपयोग करके तत्वों को अन्य तत्वों (ऑब्जेक्ट्स, सिस्टम, सबसिस्टम) पर भिन्नता से बचाता है। | ||
समस्या: | समस्या: ऑब्जेक्ट, उपप्रणालियों और प्रणालियों को कैसे डिज़ाइन किया जाए ताकि इन तत्वों में भिन्नता या अस्थिरता का अन्य तत्वों पर अवांछनीय प्रभाव न पड़े?<br> | ||
समाधान: अनुमानित भिन्नता या अस्थिरता के बिंदुओं की पहचान करें; उनके चारों ओर एक स्थिर इंटरफ़ेस बनाने के लिए जिम्मेदारियाँ सौंपें। | समाधान: अनुमानित भिन्नता या अस्थिरता के बिंदुओं की पहचान करें; उनके चारों ओर एक स्थिर इंटरफ़ेस बनाने के लिए जिम्मेदारियाँ सौंपें। | ||
| Line 96: | Line 93: | ||
* [[डिज़ाइन पैटर्न (कंप्यूटर विज्ञान)]] | * [[डिज़ाइन पैटर्न (कंप्यूटर विज्ञान)]] | ||
* डिज़ाइन पैटर्न (पुस्तक)|डिज़ाइन पैटर्न (पुस्तक) | * डिज़ाइन पैटर्न (पुस्तक)|डिज़ाइन पैटर्न (पुस्तक) | ||
* ठोस ( | * ठोस (ऑब्जेक्ट-अभिविन्यस्त डिजाइन) | ||
==संदर्भ== | ==संदर्भ== | ||
Revision as of 09:01, 4 July 2023
सामान्य उत्तरदायित्व असाइनमेंट सॉफ़्टवेयर पैटर्न (या सिद्धांत), संक्षिप्त रूप से जीआरएएसपी, "ऑब्जेक्ट-अभिविन्यस्त डिज़ाइन और उत्तरदायित्व असाइनमेंट में नौ मूलभूत सिद्धांतों" का एक समूह है[1]: 6 जिसमे पहली बार क्रेग लर्मन ने अपनी 1997 की पुस्तक एप्लाइंग यूएमएल एंड पैटर्न्स में प्रकाशित किया था।
जीआरएएसपी में उपयोग किए जाने वाले विभिन्न पैटर्न और सिद्धांत नियंत्रक, निर्माता, अप्रत्यक्ष, सूचना विशेषज्ञ, कम युग्मन (कंप्यूटर विज्ञान), उच्च सामंजस्य (कंप्यूटर विज्ञान), बहुरूपता (ऑब्जेक्ट-अभिविन्यस्त प्रोग्रामिंग), संरक्षित विविधताएं और शुद्ध निर्माण हैं।[2]ये सभी पैटर्न कई सॉफ्टवेयर विकास परियोजनाओं में आम तौर पर होने वाली कुछ सॉफ्टवेयर समस्याओं को हल करते हैं। इन तकनीकों का आविष्कार काम करने के नए तरीके बनाने के लिए नहीं किया गया है, बल्कि ऑब्जेक्ट-ओरिएंटेड डिज़ाइन में पुराने, आज़माए और परीक्षण किए गए कंप्यूटर प्रोग्रामिंग सिद्धांतों को बेहतर दस्तावेज़ और मानकीकृत करने के लिए किया गया है।
क्रेग लार्मन का कहना है कि सॉफ़्टवेयर विकास के लिए महत्वपूर्ण डिज़ाइन टूल डिज़ाइन सिद्धांतों में अच्छी तरह से शिक्षित दिमाग है। यह एकीकृत मॉडलिंग भाषा या कोई अन्य तकनीक नहीं है।[3]: 272 इस प्रकार, जीआरएएसपी सिद्धांत वास्तव में एक मानसिक टूलसमूह हैं, जो ऑब्जेक्ट-ओरिएंटेड सॉफ़्टवेयर के डिज़ाइन में मदद करने के लिए एक शिक्षण सहायता है।
पैटर्न
ऑब्जेक्ट-ओरिएंटेड डिज़ाइन में, एक पैटर्न किसी समस्या और समाधान का नामित विवरण होता है जिसे नए संदर्भों में लागू किया जा सकता है; आदर्श रूप से, एक पैटर्न हमें सलाह देता है कि अलग-अलग परिस्थितियों में इसके समाधान को कैसे लागू किया जाए और ताकतों और व्यापार-बंदों पर विचार किया जाए। कई पैटर्न, समस्या की एक विशिष्ट श्रेणी को देखते हुए, ऑब्जेक्ट को जिम्मेदारियों के असाइनमेंट का मार्गदर्शन करते हैं।
सूचना विशेषज्ञ
समस्या: एक बुनियादी सिद्धांत क्या है जिसके द्वारा ऑब्जेक्ट को जिम्मेदारियाँ सौंपी जाती हैं?
समाधान: उस वर्ग को जिम्मेदारी सौंपें जिसके पास इसे पूरा करने के लिए आवश्यक जानकारी है।
सूचना विशेषज्ञ (विशेषज्ञ या विशेषज्ञ सिद्धांत भी) एक सिद्धांत है जिसका उपयोग यह निर्धारित करने के लिए किया जाता है कि विधियों, गणना किए गए क्षेत्रों आदि जैसी जिम्मेदारियों को कहां सौंपा जाए।
सूचना विशेषज्ञ के सिद्धांत का उपयोग करते हुए, ज़िम्मेदारियाँ सौंपने का एक सामान्य दृष्टिकोण किसी दी गई ज़िम्मेदारी को देखना, उसे पूरा करने के लिए आवश्यक जानकारी का निर्धारण करना और फिर यह निर्धारित करना है कि वह जानकारी कहाँ संग्रहीत है।
इससे कक्षा पर यह जिम्मेदारी डाली जाएगी कि उसे पूरा करने के लिए सबसे अधिक जानकारी की आवश्यकता होगी।[3]: 17:11
संबंधित पैटर्न या सिद्धांत: कम युग्मन, उच्च सामंजस्य
निर्माता
ऑब्जेक्ट का निर्माण किसी ऑब्जेक्ट-अभिविन्यस्त प्रणाली में सबसे आम गतिविधियों में से एक है। ऑब्जेक्ट के निर्माण के लिए कौन सा वर्ग जिम्मेदार है, यह विशेष वर्गों की ऑब्जेक्ट के बीच संबंध की एक मौलिक संपत्ति है।
समस्या: ऑब्जेक्ट कौन बनाता है A?
समाधान: सामान्य तौर पर, कक्षा निर्दिष्ट करें B ऑब्जेक्ट बनाने की जिम्मेदारी A यदि निम्नलिखित में से एक, या अधिमानतः अधिक, लागू हो:
- के उदाहरण
Bके उदाहरणों को शामिल करना या समग्र रूप से एकत्रित करनाA - के उदाहरण
Bके उदाहरण रिकॉर्ड करेंA - के उदाहरण
Bके उदाहरणों का बारीकी से उपयोग करेंA - के उदाहरण
Bके उदाहरणों के लिए प्रारंभिक जानकारी हैAऔर इसे सृजन को सौंपें।[3]: 16:16.7
संबंधित पैटर्न या सिद्धांत: कम युग्मन, फ़ैक्टरी पैटर्न
नियंत्रक
नियंत्रक पैटर्न सिस्टम घटनाओं से निपटने की ज़िम्मेदारी एक गैर-उपयोगकर्ता इंटरफ़ेस वर्ग को सौंपता है जो समग्र सिस्टम या उपयोग केस परिदृश्य का प्रतिनिधित्व करता है। कंट्रोलर ऑब्जेक्ट एक प्रयोक्ता इंटरफ़ेस ऑब्जेक्ट है जो सिस्टम इवेंट को प्राप्त करने या संभालने के लिए जिम्मेदार है।
समस्या: इनपुट सिस्टम इवेंट को संभालने के लिए कौन जिम्मेदार होना चाहिए?
समाधान: एक उपयोग मामले नियंत्रक का उपयोग किसी उपयोग मामले की सभी सिस्टम घटनाओं से निपटने के लिए किया जाना चाहिए, और इसका उपयोग एक से अधिक उपयोग मामलों के लिए किया जा सकता है। उदाहरण के लिए, उपयोगकर्ता बनाएं और उपयोगकर्ता हटाएं उपयोग मामलों के लिए, दो अलग-अलग उपयोग मामले नियंत्रकों के बजाय, उपयोगकर्ता नियंत्रक नामक एक एकल वर्ग हो सकता है। वैकल्पिक रूप से एक मुखौटा नियंत्रक का उपयोग किया जाएगा; यह तब लागू होता है जब घटना को संभालने की जिम्मेदारी वाली ऑब्जेक्ट समग्र प्रणाली या मूल ऑब्जेक्ट का प्रतिनिधित्व करती है।
नियंत्रक को यूआई परत से परे पहली ऑब्जेक्ट के रूप में परिभाषित किया गया है जो सिस्टम ऑपरेशन को प्राप्त करता है और समन्वयित (नियंत्रित) करता है। नियंत्रक को उस कार्य को अन्य ऑब्जेक्ट को सौंपना चाहिए जिसे करने की आवश्यकता है; यह गतिविधि का समन्वय या नियंत्रण करता है। इसे खुद ज्यादा काम नहीं करना चाहिए. जीआरएएसपी नियंत्रक को एप्लिकेशन/सेवा परत का एक हिस्सा माना जा सकता है[4](यह मानते हुए कि एप्लिकेशन ने एक सूचना प्रणाली तार्किक वास्तुकला में सामान्य परतों के साथ ऑब्जेक्ट-ओरिएंटेड सिस्टम में एप्लिकेशन/सेवा परत और डोमेन परत के बीच एक स्पष्ट अंतर बनाया है)।
संबंधित पैटर्न या सिद्धांत: कमांड_पैटर्न, फेकाडे_पैटर्न, लेयर_(ऑब्जेक्ट-ओरिएंटेड_डिज़ाइन), शुद्ध निर्माण
निर्देश
अप्रत्यक्ष पैटर्न कम युग्मन का समर्थन करता है और दो तत्वों के बीच मध्यस्थता की जिम्मेदारी एक मध्यवर्ती ऑब्जेक्ट को सौंपकर उनके बीच क्षमता का पुन: उपयोग करता है। इसका एक उदाहरण मॉडल-व्यू-नियंत्रक पैटर्न में डेटा (मॉडल) और उसके प्रतिनिधित्व (दृश्य) के बीच मध्यस्थता के लिए एक नियंत्रक घटक की शुरूआत है। यह सुनिश्चित करता है कि उनके बीच युग्मन कम रहे।
समस्या: दो (या अधिक) चीजों के बीच सीधे जुड़ाव से बचने के लिए जिम्मेदारी कहां सौंपी जाए? ऑब्जेक्ट को कैसे अलग करें ताकि कम युग्मन समर्थित हो और पुन: उपयोग की क्षमता अधिक बनी रहे?
समाधान: अन्य घटकों या सेवाओं के बीच मध्यस्थता करने के लिए एक मध्यवर्ती ऑब्जेक्ट को जिम्मेदारी सौंपें ताकि वे सीधे युग्मित न हों।
मध्यस्थ अन्य घटकों के बीच एक अप्रत्यक्ष संबंध बनाता है।
कम युग्मन
युग्मन इस बात का माप है कि एक तत्व कितनी मजबूती से जुड़ा हुआ है, उसे अन्य तत्वों का ज्ञान है या वह उस पर निर्भर है। कम युग्मन एक मूल्यांकनात्मक पैटर्न है जो निम्नलिखित लाभों के लिए ज़िम्मेदारियाँ सौंपने का निर्देश देता है:
- वर्गों के बीच कम निर्भरता,
- एक वर्ग में परिवर्तन से दूसरे वर्गों पर कम प्रभाव पड़ता है,
- उच्च पुन: उपयोग क्षमता।
उच्च सामंजस्य
उच्च सामंजस्य एक मूल्यांकन पैटर्न है जो ऑब्जेक्ट को उचित रूप से केंद्रित, प्रबंधनीय और समझने योग्य रखने का प्रयास करता है। उच्च सामंजस्य का उपयोग आम तौर पर कम युग्मन के समर्थन में किया जाता है। उच्च सामंजस्य का अर्थ है कि तत्वों के दिए गए समूह की जिम्मेदारियाँ दृढ़ता से संबंधित हैं और एक विशिष्ट विषय पर अत्यधिक केंद्रित हैं। प्रोग्रामों को वर्गों और उपप्रणालियों में तोड़ना, यदि सही ढंग से किया जाए, उन गतिविधियों का एक उदाहरण है जो नामित वर्गों और उपप्रणालियों के एकजुट गुणों को बढ़ाते हैं। वैकल्पिक रूप से, कम सामंजस्य एक ऐसी स्थिति है जिसमें तत्वों के एक समूह, उदाहरण के लिए, एक उपप्रणाली, पर बहुत अधिक असंबंधित जिम्मेदारियां होती हैं। अपने घटक तत्वों के बीच कम सामंजस्य वाले उपप्रणालियों को अक्सर समग्र रूप से समझने, पुन: उपयोग करने, बनाए रखने और बदलने में कठिनाई होती है।[3]: 314–315
बहुरूपता
बहुरूपता सिद्धांत के अनुसार, प्रकार के आधार पर व्यवहारों की भिन्नता को परिभाषित करने की जिम्मेदारी उस प्रकार को सौंपी जाती है जिसके लिए यह भिन्नता होती है। यह बहुरूपता (कंप्यूटर विज्ञान) संचालन का उपयोग करके हासिल किया जाता है। प्रकार के उपयोगकर्ता को प्रकार के आधार पर स्पष्ट शाखाकरण के बजाय बहुरूपी संचालन का उपयोग करना चाहिए।
समस्या: प्रकार के आधार पर विकल्पों को कैसे संभालें? प्लग करने योग्य सॉफ़्टवेयर घटक कैसे बनाएं?
समाधान: जब संबंधित विकल्प या व्यवहार प्रकार (वर्ग) के अनुसार भिन्न होते हैं, तो व्यवहार के लिए जिम्मेदारी सौंपें - बहुरूपी संचालन का उपयोग करके - उन प्रकारों को जिनके लिए व्यवहार भिन्न होता है। (बहुरूपता के कई संबंधित अर्थ हैं। इस संदर्भ में, इसका अर्थ है विभिन्न ऑब्जेक्ट में सेवाओं को एक ही नाम देना।)
संरक्षित विविधताएं
संरक्षित विविधता पैटर्न एक इंटरफ़ेस (कंप्यूटर विज्ञान) के साथ अस्थिरता के फोकस को लपेटकर और इस इंटरफ़ेस के विभिन्न कार्यान्वयन बनाने के लिए बहुरूपता (कंप्यूटर विज्ञान) का उपयोग करके तत्वों को अन्य तत्वों (ऑब्जेक्ट्स, सिस्टम, सबसिस्टम) पर भिन्नता से बचाता है।
समस्या: ऑब्जेक्ट, उपप्रणालियों और प्रणालियों को कैसे डिज़ाइन किया जाए ताकि इन तत्वों में भिन्नता या अस्थिरता का अन्य तत्वों पर अवांछनीय प्रभाव न पड़े?
समाधान: अनुमानित भिन्नता या अस्थिरता के बिंदुओं की पहचान करें; उनके चारों ओर एक स्थिर इंटरफ़ेस बनाने के लिए जिम्मेदारियाँ सौंपें।
शुद्ध निर्माण
शुद्ध निर्माण एक ऐसा वर्ग है जो समस्या क्षेत्र में एक अवधारणा का प्रतिनिधित्व नहीं करता है, जो विशेष रूप से कम युग्मन, उच्च सामंजस्य और उससे प्राप्त पुन: उपयोग की क्षमता को प्राप्त करने के लिए बनाया गया है (जब सूचना विशेषज्ञ पैटर्न द्वारा प्रस्तुत समाधान नहीं होता है) ). इस प्रकार की कक्षा को डोमेन-संचालित डिज़ाइन में सेवा कहा जाता है।
संबंधित पैटर्न और सिद्धांत • कम युग्मन. • उच्च सामंजस्य।
यह भी देखें
- एनीमिक डोमेन मॉडल
- डिज़ाइन पैटर्न (कंप्यूटर विज्ञान)
- डिज़ाइन पैटर्न (पुस्तक)|डिज़ाइन पैटर्न (पुस्तक)
- ठोस (ऑब्जेक्ट-अभिविन्यस्त डिजाइन)
संदर्भ
- ↑ Craig Larman (2001). Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (PDF) (2nd ed.). Prentice Hall. ISBN 0-13-092569-1.
- ↑ Muhammad Umair (2018-02-26). "SOLID, GRASP, and Other Basic Principles of Object-Oriented Design". DZone.
- ↑ 3.0 3.1 3.2 3.3 Craig Larman (2004). Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd ed.). Pearson. ISBN 978-0131489066.
- ↑ "Application Layer like business facade?". Yahoo! Groups (domaindrivendesign). Archived from the original on 2020-08-07. Retrieved 2010-07-15.
