GRASP (वस्तु-उन्मुख डिज़ाइन): Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
{{short description|Guidelines in object-oriented design}}'''सामान्य उत्तरदायित्व समनुदेशन सॉफ़्टवेयर पैटर्न''' (या '''सिद्धांत'''), संक्षिप्त रूप से '''जीआरएएसपी''', [[वस्तु-उन्मुख डिज़ाइन|'''"ऑब्जेक्ट-अभिविन्यस्त डिज़ाइन''']] और उत्तरदायित्व समनुदेशन में नौ मूलभूत सिद्धांतों" का समूह है<ref name="Larman2001"/>{{rp|6}} इसमे पहली बार [[क्रेग लर्मन]] ने अपनी 1997 की पुस्तक "'''एप्लाइंग यूएमएल एंड पैटर्न्स'''" में प्रकाशित किया था। | {{short description|Guidelines in object-oriented design}}'''सामान्य उत्तरदायित्व समनुदेशन सॉफ़्टवेयर पैटर्न''' (या '''सिद्धांत'''), संक्षिप्त रूप से '''जीआरएएसपी''', [[वस्तु-उन्मुख डिज़ाइन|'''"ऑब्जेक्ट-अभिविन्यस्त डिज़ाइन''']] और उत्तरदायित्व समनुदेशन में नौ मूलभूत सिद्धांतों" का समूह है<ref name="Larman2001"/>{{rp|6}} इसमे पहली बार [[क्रेग लर्मन]] ने अपनी 1997 की पुस्तक "'''एप्लाइंग यूएमएल एंड पैटर्न्स'''" में प्रकाशित किया था। | ||
इस प्रकार से जीआरएएसपी में उपयोग किए जाने वाले विभिन्न पैटर्न और सिद्धांत नियंत्रक, निर्माता, अप्रत्यक्ष, सूचना विशेषज्ञ, निम्न [[युग्मन (कंप्यूटर विज्ञान)]], उच्च [[सामंजस्य (कंप्यूटर विज्ञान)]], [[बहुरूपता (वस्तु-उन्मुख प्रोग्रामिंग)|बहुरूपता (ऑब्जेक्ट-अभिविन्यस्त प्रोग्रामन)]], संरक्षित विविधताएं और शुद्ध निर्माण हैं।<ref name="Umair2018"/> अतः ये सभी पैटर्न कई सॉफ्टवेयर विकास परियोजनाओं में सामान्यतः होने वाले कुछ सॉफ्टवेयर समस्याओं को हल करते हैं। इस प्रकार से इन तकनीकों का आविष्कार कार्य करने की नवीन विधि बनाने के लिए नहीं किया गया है, यद्यपि ऑब्जेक्ट-अभिविन्यस्त डिज़ाइन में प्राचीन, जाँचे गए और परीक्षण किए गए [[कंप्यूटर प्रोग्रामिंग|कंप्यूटर प्रोग्रामन]] सिद्धांतों को ठीक डॉक्यूमेंट और मानकीकृत करने के लिए किया गया है। | इस प्रकार से जीआरएएसपी में उपयोग किए जाने वाले विभिन्न पैटर्न और सिद्धांत नियंत्रक, निर्माता, अप्रत्यक्ष, सूचना विशेषज्ञ, निम्न [[युग्मन (कंप्यूटर विज्ञान)]], उच्च [[सामंजस्य (कंप्यूटर विज्ञान)]], [[बहुरूपता (वस्तु-उन्मुख प्रोग्रामिंग)|बहुरूपता (ऑब्जेक्ट-अभिविन्यस्त प्रोग्रामन)]], संरक्षित विविधताएं और शुद्ध निर्माण हैं।<ref name="Umair2018"/> अतः ये सभी पैटर्न कई सॉफ्टवेयर विकास परियोजनाओं में सामान्यतः होने वाले कुछ सॉफ्टवेयर समस्याओं को पूर्ण रूप से हल करते हैं। इस प्रकार से इन तकनीकों का आविष्कार कार्य करने की नवीन विधि बनाने के लिए नहीं किया गया है, यद्यपि ऑब्जेक्ट-अभिविन्यस्त डिज़ाइन में प्राचीन, जाँचे गए और परीक्षण किए गए [[कंप्यूटर प्रोग्रामिंग|कंप्यूटर प्रोग्रामन]] सिद्धांतों को ठीक डॉक्यूमेंट और मानकीकृत करने के लिए किया गया है। | ||
इस प्रकार से क्रेग लार्मन का कहना है कि [[सॉफ़्टवेयर]] विकास के लिए महत्वपूर्ण डिज़ाइन टूल डिज़ाइन सिद्धांतों में ठीक रूप से शिक्षित मस्तिष्क है। अतः यह [[एकीकृत मॉडलिंग भाषा]] या कोई अन्य तकनीक नहीं है।<ref name="Larman2004"/>{{rp|272}} इस प्रकार, जीआरएएसपी सिद्धांत वस्तुतः मानसिक टूलसेट हैं, जो ऑब्जेक्ट-अभिविन्यस्त सॉफ़्टवेयर के डिज़ाइन में सहायता करने के लिए शिक्षण सहायता है। | इस प्रकार से क्रेग लार्मन का कहना है कि [[सॉफ़्टवेयर]] विकास के लिए महत्वपूर्ण डिज़ाइन टूल डिज़ाइन सिद्धांतों में ठीक रूप से शिक्षित मस्तिष्क है। अतः यह [[एकीकृत मॉडलिंग भाषा]] या कोई अन्य तकनीक नहीं है।<ref name="Larman2004"/>{{rp|272}} इस प्रकार, जीआरएएसपी सिद्धांत वस्तुतः मानसिक टूलसेट हैं, जो ऑब्जेक्ट-अभिविन्यस्त सॉफ़्टवेयर के डिज़ाइन में सहायता करने के लिए शिक्षण सहायता है। | ||
| Line 11: | Line 11: | ||
{{see also|सूचना प्रच्छादन}} | {{see also|सूचना प्रच्छादन}} | ||
समस्या: मूलभूत सिद्धांत क्या है जिसके द्वारा ऑब्जेक्ट को उत्तरदायित्व | समस्या: मूलभूत सिद्धांत क्या है जिसके द्वारा ऑब्जेक्ट को उत्तरदायित्व निर्दिष्ट किया जाता हैं?<br>हल: उस वर्ग को उत्तरदायित्व निर्दिष्ट करें जिसके निकट इसे पूर्ण करने के लिए आवश्यक सूचना है। | ||
'''सूचना विशेषज्ञ''' ('''विशेषज्ञ''' या '''विशेषज्ञ सिद्धांत''' भी) सिद्धांत है जिसका उपयोग यह निर्धारित करने के लिए किया जाता है कि विधियों, गणना किए गए क्षेत्रों आदि जैसी उत्तरदायित्वों को कहां | '''सूचना विशेषज्ञ''' ('''विशेषज्ञ''' या '''विशेषज्ञ सिद्धांत''' भी) सिद्धांत है जिसका उपयोग यह निर्धारित करने के लिए किया जाता है कि विधियों, गणना किए गए क्षेत्रों आदि जैसी उत्तरदायित्वों को कहां निर्दिष्ट किया जाए। | ||
इस प्रकार से इस सूचना विशेषज्ञ के सिद्धांत का उपयोग करते हुए, उत्तरदायित्व | इस प्रकार से इस सूचना विशेषज्ञ के सिद्धांत का उपयोग करते हुए, उत्तरदायित्व निर्दिष्ट करने का सामान्य दृष्टिकोण किसी दी गई उत्तरदायित्व को देखना, उसे पूर्ण करने के लिए आवश्यक सूचना का निर्धारण करना और फिर यह निर्धारित करना है कि वह सूचना कहाँ संग्रहीत है। | ||
अतः इससे वर्ग पर यह उत्तरदायित्व | अतः इससे वर्ग पर यह उत्तरदायित्व निर्दिष्ट किया जाएगा कि उसे पूर्ण करने के लिए सबसे अधिक सूचना की आवश्यकता होगी।<ref name="Larman2004"/>{{rp|17:11}} | ||
'''संबंधित पैटर्न या सिद्धांत''': निम्न युग्मन, उच्च सामंजस्य | '''संबंधित पैटर्न या सिद्धांत''': निम्न युग्मन, उच्च सामंजस्य | ||
| Line 24: | Line 24: | ||
{{see also|फ़ैक्टरी पैटर्न}} | {{see also|फ़ैक्टरी पैटर्न}} | ||
इस प्रकार से ऑब्जेक्ट का निर्माण किसी ऑब्जेक्ट-अभिविन्यस्त प्रणाली में सबसे सामान्य गतिविधियों में से है। अतः ऑब्जेक्ट के निर्माण के लिए कौन सा वर्ग उत्तरदायी है, यह विशेष वर्गों की ऑब्जेक्ट के बीच संबंध का मौलिक गुण है। | इस प्रकार से ऑब्जेक्ट का निर्माण किसी ऑब्जेक्ट-अभिविन्यस्त प्रणाली में सबसे सामान्य गतिविधियों में से है। अतः ऑब्जेक्ट के निर्माण के लिए कौन सा वर्ग पूर्ण रूप से उत्तरदायी है, यह विशेष वर्गों की ऑब्जेक्ट के बीच संबंध का मौलिक गुण है। | ||
समस्या: ऑब्जेक्ट <code>A</code> कौन बनाता है ?<br>हल: सामान्यतः, कक्षा <code>B</code> को ऑब्जेक्ट <code>A</code> बनाने का उत्तरदायित्व | समस्या: ऑब्जेक्ट <code>A</code> कौन बनाता है ?<br>हल: सामान्यतः, कक्षा <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 40: | Line 40: | ||
समस्या: इनपुट प्रणाली इवेंट को संभालने के लिए कौन उत्तरदायी होना चाहिए?<br>हल: ''उपयोग स्थिति नियंत्रक'' का उपयोग किसी उपयोग स्थिति की ''सभी'' प्रणाली घटनाओं से निपटने के लिए किया जाना चाहिए, और इसके उपयोग से अधिक उपयोग स्थितियों के लिए किया जा सकता है। इस प्रकार से [[उदाहरण]] के लिए, ''उपयोगकर्ता बनाएं'' और ''उपयोगकर्ता हटाएं'' उपयोग स्थितियों के लिए, दो अलग-अलग उपयोग स्थिति नियंत्रकों के अतिरिक्त, ''उपयोगकर्ता नियंत्रक'' नामक एकल वर्ग हो सकता है। अतः वैकल्पिक रूप से ''आच्छादन नियंत्रक'' का उपयोग किया जाएगा; यह तब लागू होता है जब घटना को संभालने की उत्तरदायित्व वाली ऑब्जेक्ट समग्र प्रणाली या मूल ऑब्जेक्ट का प्रतिनिधित्व करती है। | समस्या: इनपुट प्रणाली इवेंट को संभालने के लिए कौन उत्तरदायी होना चाहिए?<br>हल: ''उपयोग स्थिति नियंत्रक'' का उपयोग किसी उपयोग स्थिति की ''सभी'' प्रणाली घटनाओं से निपटने के लिए किया जाना चाहिए, और इसके उपयोग से अधिक उपयोग स्थितियों के लिए किया जा सकता है। इस प्रकार से [[उदाहरण]] के लिए, ''उपयोगकर्ता बनाएं'' और ''उपयोगकर्ता हटाएं'' उपयोग स्थितियों के लिए, दो अलग-अलग उपयोग स्थिति नियंत्रकों के अतिरिक्त, ''उपयोगकर्ता नियंत्रक'' नामक एकल वर्ग हो सकता है। अतः वैकल्पिक रूप से ''आच्छादन नियंत्रक'' का उपयोग किया जाएगा; यह तब लागू होता है जब घटना को संभालने की उत्तरदायित्व वाली ऑब्जेक्ट समग्र प्रणाली या मूल ऑब्जेक्ट का प्रतिनिधित्व करती है। | ||
इस प्रकार से नियंत्रक को यूआई परत के अतिरिक्त प्रथम ऑब्जेक्ट के रूप में परिभाषित किया गया है जो प्रणाली संक्रिया को प्राप्त करता है और समन्वयित (नियंत्रित) करता है। अतः नियंत्रक को उस कार्य को अन्य ऑब्जेक्ट को देना चाहिए जिसे करने की आवश्यकता है; यह गतिविधि का समन्वय या नियंत्रण करता है। इसे स्वयं अधिक कार्य नहीं करना चाहिए। जीआरएएसपी नियंत्रक को सूचना प्रणाली तार्किक संरचना में सामान्य परतों के साथ ऑब्जेक्ट-अभिविन्यस्त प्रणाली में एप्लिकेशन/सेवा परत<ref name="Yahoo" /> (यह मानते हुए कि एप्लिकेशन ने एप्लिकेशन/सेवा परत और [[डोमेन परत]] के बीच स्पष्ट अंतर किया है) का एक भाग माना जा सकता है। | इस प्रकार से नियंत्रक को यूआई परत के अतिरिक्त प्रथम ऑब्जेक्ट के रूप में परिभाषित किया गया है जो प्रणाली संक्रिया को प्राप्त करता है और समन्वयित (नियंत्रित) करता है। अतः नियंत्रक को उस कार्य को अन्य ऑब्जेक्ट को पूर्ण रूप से देना चाहिए जिसे करने की आवश्यकता है; यह गतिविधि का समन्वय या नियंत्रण करता है। इसे स्वयं अधिक कार्य नहीं करना चाहिए। जीआरएएसपी नियंत्रक को सूचना प्रणाली तार्किक संरचना में सामान्य परतों के साथ ऑब्जेक्ट-अभिविन्यस्त प्रणाली में एप्लिकेशन/सेवा परत<ref name="Yahoo" /> (यह मानते हुए कि एप्लिकेशन ने एप्लिकेशन/सेवा परत और [[डोमेन परत]] के बीच स्पष्ट अंतर किया है) का एक भाग माना जा सकता है। | ||
'''संबंधित पैटर्न या सिद्धांत''': कमांड पैटर्न, फेकाडे पैटर्न, लेयर (ऑब्जेक्ट-अभिविन्यस्त डिज़ाइन), शुद्ध निर्माण | '''संबंधित पैटर्न या सिद्धांत''': कमांड पैटर्न, फेकाडे पैटर्न, लेयर (ऑब्जेक्ट-अभिविन्यस्त डिज़ाइन), शुद्ध निर्माण | ||
| Line 47: | Line 47: | ||
इस प्रकार से अप्रत्यक्ष पैटर्न निम्न युग्मन का समर्थन करता है और दो अवयवों के बीच मध्यस्थता की उत्तरदायित्व मध्यवर्ती ऑब्जेक्ट को देकर उनके बीच क्षमता का पुन: उपयोग करता है। अतः इसका उदाहरण मॉडल-दृष्टि-नियंत्रक पैटर्न में डेटा (मॉडल) और उसके प्रतिनिधित्व (दृष्टि) के बीच मध्यस्थता के लिए नियंत्रक घटक का प्रारंभ है। यह सुनिश्चित करता है कि उनके बीच युग्मन निम्न रहे। | इस प्रकार से अप्रत्यक्ष पैटर्न निम्न युग्मन का समर्थन करता है और दो अवयवों के बीच मध्यस्थता की उत्तरदायित्व मध्यवर्ती ऑब्जेक्ट को देकर उनके बीच क्षमता का पुन: उपयोग करता है। अतः इसका उदाहरण मॉडल-दृष्टि-नियंत्रक पैटर्न में डेटा (मॉडल) और उसके प्रतिनिधित्व (दृष्टि) के बीच मध्यस्थता के लिए नियंत्रक घटक का प्रारंभ है। यह सुनिश्चित करता है कि उनके बीच युग्मन निम्न रहे। | ||
समस्या: दो (या अधिक) वस्तुओं के बीच प्रत्यक्ष संयोजन से बचने के लिए उत्तरदायित्व कहां | समस्या: दो (या अधिक) वस्तुओं के बीच प्रत्यक्ष संयोजन से बचने के लिए उत्तरदायित्व कहां निर्दिष्ट किया जाए? ऑब्जेक्ट को कैसे अलग करें ताकि '''निम्न युग्मन''' समर्थित हो और पुन: उपयोग की क्षमता अधिक बनी रहे? <br> | ||
हल: अन्य घटकों या सेवाओं के बीच मध्यस्थता करने के लिए मध्यवर्ती ऑब्जेक्ट को उत्तरदायित्व | हल: अन्य घटकों या सेवाओं के बीच मध्यस्थता करने के लिए मध्यवर्ती ऑब्जेक्ट को उत्तरदायित्व निर्दिष्ट करें जिससे कि वे प्रत्यक्षतः युग्मित न हों। <br>मध्यस्थ अन्य घटकों के बीच '''परोक्षता''' संबंध बनाता है। | ||
===निम्न युग्मन=== | ===निम्न युग्मन=== | ||
{{main|अल्प युग्मन}} | {{main|अल्प युग्मन}} | ||
इस प्रकार से युग्मन इस बात का माप है कि अवयव कितनी दृढ़ता से जुड़ा हुआ है, उसे अन्य अवयवों का ज्ञान है या वह उस पर निर्भर है। अतः निम्न युग्मन मूल्यांकनात्मक पैटर्न है जो निम्नलिखित लाभों के लिए उत्तरदायित्व | इस प्रकार से युग्मन इस बात का माप है कि अवयव कितनी दृढ़ता से जुड़ा हुआ है, उसे अन्य अवयवों का ज्ञान है या वह उस पर पूर्ण रूप से निर्भर है। अतः निम्न युग्मन मूल्यांकनात्मक पैटर्न है जो निम्नलिखित लाभों के लिए उत्तरदायित्व निर्दिष्ट करने का निर्देश देता है: | ||
* वर्गों के बीच निम्न निर्भरता, | * वर्गों के बीच निम्न निर्भरता, | ||
* एक वर्ग में परिवर्तन से दूसरे वर्गों पर निम्न प्रभाव पड़ता है, | * एक वर्ग में परिवर्तन से दूसरे वर्गों पर निम्न प्रभाव पड़ता है, | ||
| Line 67: | Line 67: | ||
{{main|ऑब्जेक्ट-अभिविन्यस्त प्रोग्रामन में बहुरूपता}} | {{main|ऑब्जेक्ट-अभिविन्यस्त प्रोग्रामन में बहुरूपता}} | ||
इस प्रकार से '''बहुरूपता''' सिद्धांत के अनुसार, प्रकार के आधार पर व्यवहारों की भिन्नता को परिभाषित करने का उत्तरदायित्व उस प्रकार को दिया जाता है जिसके लिए यह भिन्नता होती है। यह [[बहुरूपता (कंप्यूटर विज्ञान)]] संचालन का उपयोग करके प्राप्त किया जाता है। अतः इस प्रकार के उपयोगकर्ता को प्रकार के आधार पर स्पष्ट शाखाकरण के अतिरिक्त बहुरूपी संचालन का उपयोग करना चाहिए। | इस प्रकार से '''बहुरूपता''' सिद्धांत के अनुसार, प्रकार के आधार पर व्यवहारों की भिन्नता को परिभाषित करने का उत्तरदायित्व उस प्रकार को दिया जाता है जिसके लिए यह भिन्नता होती है। यह [[बहुरूपता (कंप्यूटर विज्ञान)]] संचालन का उपयोग करके पूर्ण रूप से प्राप्त किया जाता है। अतः इस प्रकार के उपयोगकर्ता को प्रकार के आधार पर स्पष्ट शाखाकरण के अतिरिक्त बहुरूपी संचालन का उपयोग करना चाहिए। | ||
समस्या: प्रकार के आधार पर विकल्पों को कैसे संभालें? प्लग करने योग्य सॉफ़्टवेयर घटक कैसे बनाएं?<br>हल: जब संबंधित विकल्प या व्यवहार प्रकार (वर्ग) के अनुसार भिन्न होते हैं, तो व्यवहार के लिए उत्तरदायित्व | समस्या: प्रकार के आधार पर विकल्पों को कैसे संभालें? प्लग करने योग्य सॉफ़्टवेयर घटक कैसे बनाएं?<br>हल: जब संबंधित विकल्प या व्यवहार प्रकार (वर्ग) के अनुसार भिन्न होते हैं, तो व्यवहार के लिए उत्तरदायित्व निर्दिष्ट करें- बहुरूपी संचालन का उपयोग करके - उन प्रकारों को जिनके लिए व्यवहार भिन्न होता है। (बहुरूपता के कई संबंधित अर्थ हैं। इस संदर्भ में, इसका अर्थ है विभिन्न ऑब्जेक्ट में सेवाओं को ही नाम देना है।) | ||
===संरक्षित विविधताएं=== | ===संरक्षित विविधताएं=== | ||
| Line 75: | Line 75: | ||
इस प्रकार से '''संरक्षित विविधता''' पैटर्न [[इंटरफ़ेस (कंप्यूटर विज्ञान)]] के साथ अस्थिरता के केंद्र को वेष्टनकर और इस इंटरफ़ेस के विभिन्न कार्यान्वयन बनाने के लिए बहुरूपता (कंप्यूटर विज्ञान) का उपयोग करके अवयवों को अन्य अवयवों (ऑब्जेक्ट, प्रणाली, उपप्रणाली) पर भिन्नता से बचाता है। | इस प्रकार से '''संरक्षित विविधता''' पैटर्न [[इंटरफ़ेस (कंप्यूटर विज्ञान)]] के साथ अस्थिरता के केंद्र को वेष्टनकर और इस इंटरफ़ेस के विभिन्न कार्यान्वयन बनाने के लिए बहुरूपता (कंप्यूटर विज्ञान) का उपयोग करके अवयवों को अन्य अवयवों (ऑब्जेक्ट, प्रणाली, उपप्रणाली) पर भिन्नता से बचाता है। | ||
समस्या: ऑब्जेक्ट, उपप्रणालियों और प्रणालियों को कैसे डिज़ाइन किया जाए ताकि इन अवयवों में भिन्नता या अस्थिरता का अन्य अवयवों पर अवांछनीय प्रभाव न पड़े?<br>हल: अनुमानित भिन्नता या अस्थिरता के बिंदुओं की पहचान करें; उनके चारों ओर स्थिर इंटरफ़ेस बनाने के लिए उत्तरदायित्व | समस्या: ऑब्जेक्ट, उपप्रणालियों और प्रणालियों को कैसे डिज़ाइन किया जाए ताकि इन अवयवों में भिन्नता या अस्थिरता का अन्य अवयवों पर अवांछनीय प्रभाव न पड़े?<br>हल: अनुमानित भिन्नता या अस्थिरता के बिंदुओं की पहचान करें; उनके चारों ओर स्थिर इंटरफ़ेस बनाने के लिए उत्तरदायित्व निर्दिष्ट करें। | ||
===शुद्ध निर्माण=== | ===शुद्ध निर्माण=== | ||
Revision as of 14:29, 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.
