सॉफ्टवेयर डिजाइन पैटर्न: Difference between revisions

From Vigyanwiki
No edit summary
No edit summary
 
(3 intermediate revisions by 3 users not shown)
Line 1,005: Line 1,005:
  | isbn = 978-0-201-59607-6
  | isbn = 978-0-201-59607-6
  | archive-url = https://web.archive.org/web/20070617114432/http://www.cix.co.uk/~smallmemory | archive-date = 2007-06-17 }}
  | archive-url = https://web.archive.org/web/20070617114432/http://www.cix.co.uk/~smallmemory | archive-date = 2007-06-17 }}
{{refend}}
{{refend}}{{Authority control}}


{{Design Patterns patterns}}
[[Category:All articles with unsourced statements]]
{{Authority control}}
[[Category:Articles with unsourced statements from August 2014]]
[[Category: सॉफ्टवेयर डिजाइन पैटर्न | सॉफ्टवेयर डिजाइन पैटर्न ]] [[Category: सॉफ्टवेयर डेवलपमेंट]]  
[[Category:CS1 errors]]
 
[[Category:CS1 maint]]
 
 
[[Category: Machine Translated Page]]
[[Category:Created On 02/03/2023]]
[[Category:Created On 02/03/2023]]
[[Category:Lua-based templates]]
[[Category:Machine Translated Page]]
[[Category:Multi-column templates]]
[[Category:Pages using div col with small parameter]]
[[Category:Pages with script errors]]
[[Category:Short description with empty Wikidata description]]
[[Category:Templates Vigyan Ready]]
[[Category:Templates that add a tracking category]]
[[Category:Templates that generate short descriptions]]
[[Category:Templates using TemplateData]]
[[Category:Templates using under-protected Lua modules]]
[[Category:Wikipedia fully protected templates|Div col]]
[[Category:सॉफ्टवेयर डिजाइन पैटर्न| सॉफ्टवेयर डिजाइन पैटर्न ]]
[[Category:सॉफ्टवेयर डेवलपमेंट]]

Latest revision as of 09:36, 17 March 2023

एचटीटीपी स्विचबोर्ड सॉफ्टवेयर इंजीनियरिंग में,एक सॉफ्टवेर डिज़ाइन पैटर्न सॉफ़्टवेयर डिज़ाइन में दिए गए संदर्भ में सामान्य रूप से होने वाली समस्या का एक सामान्य, पुन: प्रयोज्य हल है। यह एक तैयार डिज़ाइन नहीं है जिसे सीधे सोर्स कोड या मशीन कोड में बदला जा सकता है। वस्तुतः, यह किसी समस्या को कैसे हल किया जाए, इसका विवरण या टेम्पलेट है जिसका उपयोग कई अलग-अलग स्थितियों में किया जा सकता है। डिज़ाइन पैटर्न औपचारिक रूप से सर्वोत्तम कार्यप्रणाली हैं जिनका उपयोग प्रोग्रामर किसी एप्लिकेशन या प्रणाली को डिज़ाइन करते समय सामान्य समस्याओं को हल करने के लिए कर सकता है।

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

डिजाइन पैटर्न को एक प्रोग्रामिंग प्रतिमान के स्तरों और एक मूर्त अल्गोरिथम के बीच कंप्यूटर प्रोग्रामिंग मध्यम के लिए संरचित दृष्टिकोण के रूप में देखा जा सकता है।

इतिहास

1977 की प्रारम्भ में क्रिस्टोफर अलेक्जेंडर द्वारा एक पैटर्न (वास्तुकला) के रूप में पैटर्न की उत्पत्ति हुई (c.f. द पैटर्न ऑफ स्ट्रीट्स, जर्नल ऑफ द एआईपी, सितंबर, 1966, वॉल्यूम 32, नंबर 5, पीपी। 273-278)। 1987 में, केंट बेक और वार्ड कनिंघम ने प्रोग्रामिंग के लिए पैटर्न लागू करने के विचार के साथ प्रयोग करना प्रारम्भ किया - विशेष रूप से पैटर्न भाषाओं - और उस वर्ष ओओपीएसएलए सम्मेलन में अपने परिणाम प्रस्तुत किए।[1][2] बाद के वर्षों में, बेक, कनिंघम और अन्य लोगों ने इस कार्य को आगे बढ़ाया।

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

यद्यपि डिजाइन पैटर्न यथार्थता लंबे समय से लागू किए गए हैं, डिजाइन पैटर्न की अवधारणा की औपचारिकता कई वर्षों तक चली।[3]


कार्य

डिजाइन पैटर्न परीक्षण किए गए, सिद्ध विकास प्रतिमान प्रदान करके विकास प्रक्रिया को गति दे सकते हैं।[4] प्रभावी सॉफ़्टवेयर डिज़ाइन के लिए उन समस्याओं पर विचार करने की आवश्यकता होती है जो बाद में कार्यान्वयन में दिखाई नहीं दे सकते हैं। धृष्टतापूर्वक लिखे गए कोड में प्रायः छिपी हुई जटिल समस्याएँ हो सकती हैं जिनका पता लगाने में समय लगता है, ऐसी समस्याएँ जो कभी-कभी सड़क पर बड़ी समस्या उत्पन्न कर सकती हैं। डिज़ाइन पैटर्न का पुन: उपयोग करने से ऐसे जटिल समस्याओं को रोकने में सहायता मिलती है,[5] और यह कोडर्स और स्थापत्य के लिए कोड पठनीयता में भी सुधार करता है जो पैटर्न से परिचित हैं।

नम्यता को प्राप्त करने के लिए, डिज़ाइन पैटर्न सामान्यतः संकेत के अतिरिक्त स्तर प्रस्तावित करते हैं, जो कुछ स्थितियों में परिणामी डिज़ाइन को जटिल बना सकते हैं और एप्लिकेशन निष्पादन को क्षति पहुंचा सकते हैं।

परिभाषा के अनुसार, पैटर्न का उपयोग करने वाले प्रत्येक एप्लिकेशन में फिर से प्रोग्राम किया जाना चाहिए। चूंकि कुछ लेखक इसे सॉफ़्टवेयर पुन: उपयोग से एक पश्च चरण के रूप में देखते हैं, जैसा कि सॉफ़्टवेयर घटक द्वारा प्रदान किया गया है, शोधकर्ताओं ने पैटर्न को घटकों में बदलने के लिए काम किया है। मेयर और अर्नौट अपने द्वारा किए गए पैटर्न के दो-तिहाई भाग के पूर्ण या आंशिक घटक प्रदान करने में सक्षम थे।[6]

सॉफ्टवेयर डिजाइन तकनीकों को समस्याओं की व्यापक श्रेणी में लागू करना कठिन है।[citation needed] डिज़ाइन पैटर्न सामान्य हल प्रदान करते हैं, ऐसे प्रारूप में प्रलेखन जिसमें किसी विशेष समस्या से जुड़ी विशिष्टताओं की आवश्यकता नहीं होती है।

संरचना

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

डोमेन-विशिष्ट पैटर्न

विशेष डोमेन में डिज़ाइन पैटर्न को संहिताबद्ध करने के प्रयास भी किए गए हैं, जिसमें वर्तमान डिज़ाइन पैटर्न के साथ-साथ डोमेन-विशिष्ट डिज़ाइन पैटर्न का उपयोग भी सम्मिलित है। उदाहरणों में उपयोगकर्ता इंटरफ़ेस डिज़ाइन पैटर्न,[7] सूचना दृश्य,[8] सुरक्षित डिजाइन,[9] सुरक्षित उपयोगिता,[10] वेब डिजाइन [11] और व्यापार मॉडल डिजाइन सम्मिलित हैं।[12]

प्रोग्रामिंग सम्मेलन अग्रगमन का वार्षिक पैटर्न भाषाओं [13] डोमेन-विशिष्ट पैटर्न के कई उदाहरण सम्मिलित हैं।

वर्गीकरण और सूची

डिज़ाइन पैटर्न को मूल रूप से 3 उप-वर्गीकरणों में वर्गीकृत किया गया था, जिसके आधार पर वे किस प्रकार की समस्या को हल करते हैं। रचनात्मक पैटर्न आवश्यक मानदंड के आधार पर और नियंत्रित विधि से ऑब्जेक्ट को बनाने की क्षमता प्रदान करते हैं। संरचनात्मक पैटर्न विभिन्न वर्गों और ऑब्जेक्ट को बड़ी संरचना बनाने और नवीन कार्यक्षमता प्रदान करने के लिए व्यवस्थित करने के विषय में हैं। अंत में, व्यवहारिक पैटर्न ऑब्जेक्ट के बीच सामान्य संचार पैटर्न की पहचान करने और इन पैटर्नों को साकार करने के विषय में हैं।

रचनात्मक पैटर्न

नाम विवरण डिजाइन पैटर्न में कोड पूर्ण में[14] अन्य
एब्स्ट्रैक्ट फैक्ट्री विशिष्ट वर्गों को निर्दिष्ट किए बिना संबंधित या आश्रित ऑब्जेक्ट के वर्ग बनाने के लिए एक इंटरफ़ेस प्रदान करें। Yes Yes —
बिल्डर एक जटिल ऑब्जेक्ट के निर्माण को उसके अभ्यावेदन से अलग करें, जिससे एक ही निर्माण प्रक्रिया को विभिन्न अभ्यावेदन बनाने की अनुमति मिलती है। Yes No —
डिपेंडेंसी इंजेक्शन वर्ग ऑब्जेक्ट को सीधे बनाने के अतिरिक्त एक इंजेक्टर से आवश्यक ऑब्जेक्ट को स्वीकार करता है। No No —
फैक्टरी विधि एकल ऑब्जेक्ट बनाने के लिए एक इंटरफ़ेस को परिभाषित करें, परन्तु उपवर्गों को यह निर्धारित करने दें कि किस वर्ग को तत्काल करना है। फ़ैक्टरी विधि एक वर्ग को उपवर्गों के लिए तात्कालिकता को स्थगित करने देती है। Yes Yes —
मन्द आरंभीकरण किसी ऑब्जेक्ट के निर्माण, किसी मान की गणना, या किसी अन्य महंगी प्रक्रिया में पहली बार आवश्यकता होने तक देरी करने की युक्ति। यह पैटर्न जीओएफ कैटलॉग में "वास्तविक प्रॉक्सी" के रूप में दिखाई देता है, जो प्रॉक्सी पैटर्न के लिए एक कार्यान्वयन कार्यनीति है। No No PoEAA[15]
मल्टीटन सुनिश्चित करें कि एक वर्ग ने मात्र उदाहरणों का नाम दिया है, और उन तक पहुंच का वैश्विक बिंदु प्रदान करें। No No —
ऑब्जेक्ट पूल उन ऑब्जेक्ट को रिसाइकिल करके महंगे अधिग्रहण और संसाधनों की रिलीज से बचें जो अब उपयोग में नहीं हैं। संपर्क पूल और थ्रेड पूल पैटर्न का सामान्यीकरण माना जा सकता है। No No —
प्रोटोटाइप एक प्रोटोटाइप उदाहरण का उपयोग करके बनाने के लिए ऑब्जेक्ट के प्रकार निर्दिष्ट करें, और वर्तमान ऑब्जेक्ट के 'ढांचे' से नवीन ऑब्जेक्ट बनाएं, इस प्रकार निष्पादन को बढ़ावा दें और मेमोरी फूटप्रिंट्स को न्यूनतम रखें। Yes No —
संसाधन अधिग्रहण आरंभीकरण है (आरएआईआई) सुनिश्चित करें कि संसाधनों को उपयुक्त ऑब्जेक्ट के जीवन काल से बांधकर ठीक से जारी किया गया है। No No —
एकाकी ऑब्जेक्ट सुनिश्चित करें कि वर्ग का मात्र एक उदाहरण है, और इसके लिए एक वैश्विक बिंदु प्रदान करें। Yes Yes —


संरचनात्मक पैटर्न

नाम विवरण डिजाइन पैटर्न में कोड पूर्ण में[14] अन्य
अडैप्टर, आवरण, या अनुवादक वर्ग के इंटरफ़ेस को दूसरे इंटरफ़ेस में परिवर्तित करें जिसकी क्लाइंट अपेक्षा करते हैं। एडेप्टर कक्षाओं को एक साथ काम करने देता है जो अन्यथा असंगत इंटरफेस के कारण नहीं हो सकता। उद्यम एकीकरण पैटर्न समतुल्य अनुवादक है। Yes Yes —
ब्रिज इसके कार्यान्वयन से अमूर्तता को कम करें जिससे दोनों स्वतंत्र रूप से भिन्न हो सकें। Yes Yes —
कम्पोजिट आंशिक-संपूर्ण पदानुक्रमों का प्रतिनिधित्व करने के लिए ऑब्जेक्ट को ट्री संरचनाओं में लिखें। समग्र क्लाइंटों को विशिष्ट ऑब्जेक्ट और ऑब्जेक्ट की रचनाओं को समान रूप से व्यवहार करने देता है। Yes Yes —
डेकोरेटर एक ही इंटरफ़ेस को गतिशील रूप से रखते हुए किसी ऑब्जेक्ट को अतिरिक्त ज़िम्मेदारियाँ संलग्न करें। डेकोरेटर कार्यक्षमता बढ़ाने के लिए उपवर्गीकरण का एक नम्यविकल्प प्रदान करते हैं। Yes Yes —
प्रतिनिधान उपवर्गीकरण के अतिरिक्त रचना द्वारा एक वर्ग का विस्तार करें। ऑब्जेक्ट दूसरे ऑब्जेक्ट (प्रतिनिधि) को प्रत्यायोजित कर एक अनुरोध को संभालती है — — —
एक्सटेंशन ऑब्जेक्ट पदानुक्रम को बदले बिना पदानुक्रम में कार्यक्षमता जोड़ना। No No Agile Software Development, Principles, Patterns, and Practices[16]
फ़कैड उपप्रणाली में इंटरफेस के एक समूह के लिए एकीकृत इंटरफ़ेस प्रदान करें। फ़कैड एक उच्च-स्तरीय इंटरफ़ेस को परिभाषित करता है जो उपप्रणाली को उपयोग में सरल बनाता है। Yes Yes —
फ्लाईवेट बड़ी संख्या में समान ऑब्जेक्ट का दक्षतापूर्वक सपोर्ट के लिए साझाकरण का उपयोग करें। Yes No —
फ्रंट कंट्रोलर पैटर्न वेब अनुप्रयोगों के डिजाइन से संबंधित है। यह अनुरोधों को संभालने के लिए एक केंद्रीकृत प्रवेश बिंदु प्रदान करता है। No No

J2EE Patterns[17] PoEAA[18]

मार्कर मेटाडेटा को एक वर्ग के साथ जोड़ने के लिए रिक्त इंटरफ़ेस। No No Effective Java[19]
मॉडुल कई संबंधित अवयवों को समूहित करें, जैसे कि कक्षाएं, सिंगलटन, विधियाँ, विश्व स्तर पर उपयोग की जाने वाली एकल वैचारिक इकाई में। No No —
प्रॉक्सी किसी अन्य ऑब्जेक्ट तक अभिगम को नियंत्रित करने के लिए एक प्रतिनिधि या स्थानधारक प्रदान करें। Yes No —
ट्विन[20] ट्विन उन प्रोग्रामिंग भाषाओं में एकाधिक वंशानुक्रम के मॉडलिंग की अनुमति देता है जो इस सुविधा का सपोर्ट नहीं करती हैं। No No —


व्यवहार पैटर्न

नाम विवरण डिजाइन पैटर्न में कोड पूर्ण में[14] अन्य
ब्लैकबोर्ड डेटा के असमान स्रोतों के संयोजन के लिए कृत्रिम बुद्धिमत्ता पैटर्न (ब्लैकबोर्ड प्रणाली देखें) No No —
श्रृंखला का उत्तरदायित्व एक से अधिक ऑब्जेक्ट को अनुरोध को संभालने का अवसर देकर अनुरोध के प्रेषक को उसके प्राप्तकर्ता के साथ जोड़ने से बचें। प्राप्तकर्ता ऑब्जेक्ट्स को श्रृंखलित करें और श्रृंखला के साथ अनुरोध पास करें जब तक कि कोई ऑब्जेक्ट इसे नहीं संभाले। Yes No —
कमांड एक अनुरोध को ऑब्जेक्ट के रूप में संपुटित करें, जिससे विभिन्न अनुरोधों वाले क्लाइंटों के पैरामीटरकरण और अनुरोधों की पंक्ति या लॉगिंग की अनुमति मिलती है। यह पूर्ववत संचालन के सपोर्ट के लिए भी अनुमति देता है। Yes No —
इंटरप्रेटर किसी भाषा को देखते हुए, उसके व्याकरण के लिए प्रतिनिधित्व परिभाषित करें, साथ ही एक इंटरप्रेटर जो भाषा में वाक्यों की व्याख्या करने के लिए प्रतिनिधित्व का उपयोग करता है। Yes No —
इटरेटर इसके अंतर्निहित प्रतिनिधित्व को उद्भासन किए बिना एक संयुक्त ऑब्जेक्ट के अवयवों को क्रमिक रूप से अभिगम करने की एक विधि प्रदान करें। Yes Yes —
मीडिएटर एक ऑब्जेक्ट को परिभाषित करें जो यह बताती है कि ऑब्जेक्ट का एक समूह कैसे परस्पर क्रिया करता है। मध्यस्थ ऑब्जेक्ट को एक दूसरे से स्पष्ट रूप से संदर्भित करके अस्पष्ट युग्मन को बढ़ावा देता है, और यह उनकी परस्पर क्रिया को स्वतंत्र रूप से भिन्न करने की अनुमति देता है। Yes No —
मोमेंटो संपुटीकरण का उल्लंघन किए बिना, किसी ऑब्जेक्ट की आंतरिक स्थिति को कैप्चर और बहिर्वर्त्ती करें जिससे ऑब्जेक्ट को बाद में इस स्थिति में पुनः संग्रहीत किया जा सके। Yes No —
अशक्त ऑब्जेक्ट एक डिफ़ॉल्ट ऑब्जेक्ट प्रदान करके अशक्त संदर्भों से बचें। No No —
समीक्षक या प्रकाशित/सदस्यता ऑब्जेक्ट के बीच एक-से-कई निर्भरता को परिभाषित करें जहां ऑब्जेक्ट में स्थिति परिवर्तन के परिणामस्वरूप उसके सभी आश्रितों को स्वचालित रूप से अधिसूचित और अद्यतन किया जाता है। Yes Yes —
सर्वेंट वर्गों के समूह के लिए सामान्य कार्यक्षमता को परिभाषित करें। सर्वेंट पैटर्न को प्रायः वर्गों के दिए गए समूह के लिए सहायक वर्ग या उपयोगिता वर्ग कार्यान्वयन भी कहा जाता है। सहायक वर्गों के समीप सामान्यतः कोई ऑब्जेक्ट नहीं होती है इसलिए उनके समीप सभी स्थिरविधियां होती हैं जो विभिन्न प्रकार की कक्षा ऑब्जेक्ट पर कार्य करती हैं। No No —
विनिर्देश बूलियन कार्य प्रणाली में पुन: संयोजन योग्य व्यापारिक तर्क । No No —
स्थिति जब किसी ऑब्जेक्ट की आंतरिक स्थिति बदलती है तो उसे अपने व्यवहार को बदलने की अनुमति दें। ऑब्जेक्ट अपनी कक्षा बदलती प्रतीत होगी। Yes No —
कार्यनीति एल्गोरिदम के एक वर्ग को परिभाषित करें, प्रत्येक को संपुटित करें और उन्हें विनिमेय बनाएं। कार्यनीति एल्गोरिथम का उपयोग करने वाले क्लाइंटों से स्वतंत्र रूप से भिन्न होने देती है। Yes Yes —
टेम्पलेट विधि संचालन में एक एल्गोरिथ्म के ढांचे को परिभाषित करें, उपवर्गों के लिए कुछ चरणों को हटा दें। टेम्प्लेट विधि उपवर्गों को एल्गोरिथम की संरचना को बदले बिना एल्गोरिथम के कुछ चरणों को फिर से परिभाषित करने देती है। Yes Yes —
आगंतुक कक्षाओं के एक समूह के उदाहरणों पर किए जाने वाले संचालन का प्रतिनिधित्व करें। आगंतुक उन अवयवों के वर्गों को बदले बिना एक नवीन संचालन को परिभाषित करने देता है जिन पर वह संचालित होता है। Yes No —
धाराप्रवाह इंटरफ़ेस विधिबद्ध होने के लिए एक एपीआई डिज़ाइन करें ताकि यह एक डीएसएल के जैसे पढ़ सके। प्रत्येक विधि कॉल संदर्भ देता है जिसके माध्यम से आगामी तार्किक विधि कॉल उपलब्ध कराई जाती है। No No —


समवर्ती पैटर्न

नाम विवरण POSA2 में[21] अन्य
सक्रिय ऑब्जेक्ट विधि निष्पादन को विधि आह्वान से अलग करता है जो उनके अपने नियंत्रण के थ्रेड में रहता है। लक्ष्य अतुल्यकालिक विधि आह्वान और अनुरोधों को संभालने के लिए अनुसूचक का उपयोग करके समरूपता प्रस्तावित करना है। Yes —
बाल्किंग किसी ऑब्जेक्ट पर मात्र तभी क्रिया निष्पादित करें जब ऑब्जेक्ट किसी विशेष अवस्था में हो। No —
बाध्यकारी गुण विभिन्न ऑब्जेक्ट में गुणों को किसी न किसी प्रकार से तुल्यकालित या समन्वित करने के लिए कई पर्यवेक्षकों का संयोजन।[22] No —
कर्नेल की गणना समानांतर में ही गणना कई बार, गैर-ब्रांचिंग पॉइंटर गणित के साथ उपयोग किए जाने वाले पूर्णांक मापदंडों द्वारा साझा सरणियों में भिन्न होती है, जैसे कि जीपीयू-अनुकूलित आव्यूह

गुणन या संवलनात्मक तंत्रिका नेटवर्क।

No —
डबल-चेक लॉकिंग पहले लॉकिंग मानदंड ('लॉक हिंट') का असुरक्षित विधि से परीक्षण करके लॉक प्राप्त करने के उपरि को कम करें; मात्र यदि यह सफल होता है तो वास्तविक लॉकिंग तर्क आगे बढ़ता है।

कुछ भाषा/हार्डवेयर संयोजनों में कार्यान्वित किए जाने पर असुरक्षित हो सकता है। इसलिए इसे कभी-कभी एक विरोधी पैटर्न माना जा सकता है।

Yes —
घटना-आधारित अतुल्यकालिक बहुथ्रेडेड प्रोग्राम में होने वाले अतुल्यकालिक पैटर्न के साथ समस्याओं का समाधान करता है।[23] No —
संरक्षित निलंबन संचालन का प्रबंधन करता है जिसके लिए लॉक को अधिग्रहित करने की आवश्यकता होती है और संचालन को निष्पादित करने से पूर्व संतुष्ट होने का निबंधन

होता है।

No —
जॉइन जॉइन-पैटर्न संदेश पास करके समवर्ती, समानांतर और वितरित प्रोग्राम लिखने की विधि प्रदान करती है। थ्रेड्स और लॉक्स के उपयोग की तुलना में, यह एक उच्च-स्तरीय प्रोग्रामिंग मॉडल है। No —
लॉक एक थ्रेड संसाधन पर "लॉक" लगाता है, अन्य थ्रेड्स को इसे अभिगम करने या संशोधित करने से रोकता है।[24] No PoEAA[15]
संदेश डिजाइन पैटर्न (एमडीपी) घटकों और अनुप्रयोगों के बीच सूचनाओं (अर्थात संदेशों) के आदान-प्रदान की अनुमति देता है। No —
मॉनिटर ऑब्जेक्ट एक ऑब्जेक्ट जिसकी विधि परस्पर बहिष्करण के अधीन हैं, इस प्रकार एक ही समय में कई ऑब्जेक्ट को गलत तरीके से इसका उपयोग करने से रोकते हैं। Yes —
रिएक्टर एक रिएक्टर ऑब्जेक्ट संसाधनों के लिए एक अतुल्यकालिक इंटरफ़ेस प्रदान करता है जिसे तुल्यकालिक रूप से नियंत्रित किया जाना चाहिए। Yes —
रीड-राइट लॉक एक ऑब्जेक्ट के लिए समवर्ती पठन अभिगम की अनुमति देता है, परन्तु लेखन कार्यों के लिए विशेष अभिगम की आवश्यकता होती है। लिखने के लिए एक अंतर्निहित सेमाफोर का उपयोग किया जा सकता है, और कॉपी-ऑन-राइट तंत्र का उपयोग किया जा सकता है या नहीं भी किया जा सकता है। No —
अनुसूचक स्पष्ट रूप से नियंत्रित करें जब थ्रेड्स एकल-थ्रेडेड कोड निष्पादित कर सकते हैं। No —
थ्रेड पूल कई कार्यों को करने के लिए कई थ्रेड्स बनाए जाते हैं, जो सामान्यतः एक पंक्ति में व्यवस्थित होते हैं। सामान्यतः, थ्रेड्स की तुलना में बहुत अधिक कार्य होते हैं। ऑब्जेक्ट पूल पैटर्न का विशेष विषय माना जा सकता है। No —
थ्रेड-विशिष्ट संग्रहण थ्रेड के लिए स्थिर या "वैश्विक" मेमोरी स्थानीय। Yes —
अनन्य स्वामित्व के साथ सुरक्षित संगामिति क्रम समवर्ती तंत्र की आवश्यकता से बचना, क्योंकि अनन्य स्वामित्व सिद्ध किया जा सकता है। यह रस्ट भाषा की एक उल्लेखनीय क्षमता है, परन्तु संकलन-समय की जाँच एकमात्र साधन नहीं है, एक प्रोग्रामर प्रायः ऐसे पैटर्न को कोड में मैन्युअल रूप से डिज़ाइन करेगा - लॉकिंग तंत्र के उपयोग को छोड़ देगा क्योंकि प्रोग्रामर का आकलन है कि किसी दिए गए चर को समवर्ती रूप से अभिगम नहीं किया जा सकता है। No —
सीपीयू परमाणु संचालन x86 और अन्य सीपीयू स्थापत्य परमाणु निर्देशों की एक श्रृंखला का सपोर्ट करते हैं जो आदिम मानों (पूर्णांक) को संशोधित करने और अभिगम करने के लिए मेमोरी सुरक्षा की गारंटी देते हैं। उदाहरण के लिए, दो थ्रेड काउंटर को सुरक्षित रूप से बढ़ा सकते हैं। इन क्षमताओं का उपयोग उपरोक्त के रूप में अन्य समवर्ती पैटर्न के तंत्र को लागू करने के लिए भी किया जा सकता है। C# भाषा इन क्षमताओं के लिए इंटरलाक्ड वर्ग का उपयोग करती है। No —


प्रलेखन

एक डिजाइन पैटर्न के लिए प्रलेखन उस संदर्भ का वर्णन करता है जिसमें पैटर्न का उपयोग किया जाता है, संदर्भ के भीतर बल जो पैटर्न हल करना चाहता है, और सुझाए गए समाधान।[25] डिजाइन पैटर्न के प्रलेखन के लिए कोई एकल, मानक प्रारूप नहीं है। वस्तुतः, विभिन्न पैटर्न लेखकों द्वारा विभिन्न प्रकार के विभिन्न स्वरूपों का उपयोग किया गया है। यद्यपि, मार्टिन फाउलर (सॉफ्टवेयर इंजीनियर) के अनुसार, कुछ पैटर्न प्रारूप दूसरों की तुलना में अधिक प्रसिद्ध हो गए हैं, और परिणामस्वरूप नए पैटर्न-लेखन प्रयासों के लिए सामान्य प्रारम्भी बिंदु बन गए हैं।[26] सामान्यतः उपयोग किए जाने वाले प्रलेखन प्रारूप का एक उदाहरण एरिक गामा, रिचर्ड हेल्म, राल्फ जॉनसन (कंप्यूटर वैज्ञानिक) और जॉन व्लिससाइड्स द्वारा उनकी पुस्तक डिजाइन पैटर्न (पुस्तक) में उपयोग किया जाता है। इसमें निम्नलिखित खंड हैं:

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

आलोचना

यह देखा गया है कि डिज़ाइन पैटर्न मात्र एक संकेत हो सकता है कि किसी दी गई प्रोग्रामिंग भाषा (उदाहरण के लिए जावा (प्रोग्रामिंग भाषा) या C ++) में कुछ सुविधाएँ अंतर्धान हैं। पीटर नॉरविग दर्शाता है कि डिज़ाइन पैटर्न पुस्तक (जो मुख्य रूप से सी ++ पर केंद्रित है) में 23 में से 16 पैटर्न लिस्प (प्रोग्रामिंग भाषा) या डायलन (प्रोग्रामिंग भाषा) में सरलीकृत या समाप्त (प्रत्यक्ष भाषा सपोर्ट के माध्यम से) हैं।[27] संबंधित अवलोकन हैनीमैन और किज़ेलेस द्वारा किए गए थे जिन्होंने आस्पेक्ट-ओरिएंटेड प्रोग्रामिंग भाषा (AspectJ) का उपयोग करके 23 डिज़ाइन पैटर्न में से कई को लागू किया और दिखाया कि 23 डिज़ाइन पैटर्न में से 17 के कार्यान्वयन से कोड-स्तरीय निर्भरताएँ हटा दी गईं। और वह आस्पेक्ट-ओरिएंटेड प्रोग्रामिंग डिज़ाइन पैटर्न के कार्यान्वयन को सरल बना सकती है।[28]पॉल ग्राहम (कंप्यूटर प्रोग्रामर) भी देखें। पॉल ग्राहम का निबंध रिवेंज ऑफ द नर्ड्स।[29]

पैटर्न का अनुचित उपयोग अनावश्यक रूप से जटिलता बढ़ा सकता है।[30]


यह भी देखें

संदर्भ

  1. ↑ Smith, Reid (October 1987). Panel on design methodology. OOPSLA '87 Addendum to the Proceedings. doi:10.1145/62138.62151. Ward cautioned against requiring too much programming at, what he termed, 'the high level of wizards.' He pointed out that a written 'pattern language' can significantly improve the selection and application of abstractions. He proposed a 'radical shift in the burden of design and implementation' basing the new methodology on an adaptation of Christopher Alexander's work in pattern languages and that programming-oriented pattern languages developed at Tektronix has significantly aided their software development efforts.
  2. ↑ Beck, Kent; Cunningham, Ward (September 1987). Using Pattern Languages for Object-Oriented Program. OOPSLA '87 workshop on Specification and Design for Object-Oriented Programming. Retrieved 2006-05-26.
  3. ↑ Baroni, Aline Lúcia; Guéhéneuc, Yann-Gaël; Albin-Amiot, Hervé (June 2003). "Design Patterns Formalization". Nantes: École Nationale Supérieure des Techniques Industrielles et des Mines de Nantes. CiteSeerX 10.1.1.62.6466. {{cite journal}}: Cite journal requires |journal= (help)
  4. ↑ Bishop, Judith. "C# 3.0 Design Patterns: Use the Power of C# 3.0 to Solve Real-World Problems". C# Books from O'Reilly Media. Retrieved 2012-05-15. If you want to speed up the development of your .NET applications, you're ready for C# design patterns -- elegant, accepted and proven ways to tackle common programming problems.
  5. ↑ Tiako, Pierre F. (31 March 2009). "Formal Modeling and Specification of Design Patterns Using RTPA". In Tiako, Pierre F (ed.). Software Applications: Concepts, Methodologies, Tools, and Applications: Concepts, Methodologies, Tools, and Applications. p. 636. doi:10.4018/978-1-60566-060-8. ISBN 9781605660615.
  6. ↑ Meyer, Bertrand; Arnout, Karine (July 2006). "Componentization: The Visitor Example" (PDF). IEEE Computer. 39 (7): 23–30. CiteSeerX 10.1.1.62.6082. doi:10.1109/MC.2006.227. S2CID 15328522.
  7. ↑ Laakso, Sari A. (2003-09-16). "यूजर इंटरफेस डिजाइन पैटर्न का संग्रह". University of Helsinki, Dept. of Computer Science. Retrieved 2008-01-31.{{cite web}}: CS1 maint: url-status (link)
  8. ↑ Heer, J.; Agrawala, M. (2006). "Software Design Patterns for Information Visualization". IEEE Transactions on Visualization and Computer Graphics. 12 (5): 853–60. CiteSeerX 10.1.1.121.4534. doi:10.1109/TVCG.2006.178. PMID 17080809. S2CID 11634997.
  9. ↑ Dougherty, Chad; Sayre, Kirk; Seacord, Robert C.; Svoboda, David; Togashi, Kazuya (2009). Secure Design Patterns (PDF). Software Engineering Institute.
  10. ↑ Garfinkel, Simson L. (2005). Design Principles and Patterns for Computer Systems That Are Simultaneously Secure and Usable (Ph.D. thesis).
  11. ↑ "Yahoo! Design Pattern Library". Archived from the original on 2008-02-29. Retrieved 2008-01-31.
  12. ↑ "How to design your Business Model as a Lean Startup?". 2010-01-06. Retrieved 2010-01-06.
  13. ↑ Pattern Languages of Programming, Conference proceedings (annual, 1994—) [1]
  14. ↑ 14.0 14.1 14.2 McConnell, Steve (June 2004). "Design in Construction". Code Complete (2nd ed.). Microsoft Press. p. 104. ISBN 978-0-7356-1967-8. Table 5.1 Popular Design Patterns
  15. ↑ 15.0 15.1 Fowler, Martin (2002). Patterns of Enterprise Application Architecture. Addison-Wesley. ISBN 978-0-321-12742-6.
  16. ↑ C. Martin, Robert (2002). "28. Extension object". Agile Software Development, Principles, Patterns, and Practices. p. 408. ISBN 978-0135974445.
  17. ↑ Alur, Deepak; Crupi, John; Malks, Dan (2003). Core J2EE Patterns: Best Practices and Design Strategies. Prentice Hall. p. 166. ISBN 978-0-13-142246-9.
  18. ↑ Fowler, Martin (2002). Patterns of Enterprise Application Architecture. Addison-Wesley. p. 344. ISBN 978-0-321-12742-6.
  19. ↑ Bloch, Joshua (2008). "Item 37: Use marker interfaces to define types". Effective Java (Second ed.). Addison-Wesley. p. 179. ISBN 978-0-321-35668-0.
  20. ↑ "Twin – A Design Pattern for Modeling Multiple Inheritance" (PDF).
  21. ↑ Schmidt, Douglas C.; Stal, Michael; Rohnert, Hans; Buschmann, Frank (2000). Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects. John Wiley & Sons. ISBN 978-0-471-60695-6.
  22. ↑ Binding Properties
  23. ↑ Nagel, Christian; Evjen, Bill; Glynn, Jay; Watson, Karli; Skinner, Morgan (2008). "Event-based Asynchronous Pattern". Professional C# 2008. Wiley. pp. 570–571. ISBN 978-0-470-19137-8.
  24. ↑ Lock Pattern
  25. ↑ Gabriel, Dick. "A Pattern Definition". Archived from the original on 2007-02-09. Retrieved 2007-03-06.
  26. ↑ Fowler, Martin (2006-08-01). "Writing Software Patterns". Retrieved 2007-03-06.
  27. ↑ Norvig, Peter (1998). Design Patterns in Dynamic Languages.
  28. ↑ Hannemann, Jan; Kiczales, Gregor (2002). "Design pattern implementation in Java and AspectJ". Proceedings of the 17th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications - OOPSLA '02. OOPSLA '02. p. 161. doi:10.1145/582419.582436. ISBN 1581134711.{{cite conference}}: CS1 maint: location (link)
  29. ↑ Graham, Paul (2002). "Revenge of the Nerds". Retrieved 2012-08-11.
  30. ↑ McConnell, Steve (2004). Code Complete: A Practical Handbook of Software Construction, 2nd Edition. p. 105.


अग्रिम पठन

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=सॉफ्टवेयर_डिजाइन_पैटर्न&oldid=110959’