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

From Vigyanwiki
No edit summary
No edit summary
Line 25: Line 25:
  | access-date = 2006-05-26}}</ref> बाद के वर्षों में, बेक, कनिंघम और अन्य लोगों ने इस कार्य को आगे बढ़ाया।
  | access-date = 2006-05-26}}</ref> बाद के वर्षों में, बेक, कनिंघम और अन्य लोगों ने इस कार्य को आगे बढ़ाया।


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


* {{cite book
* {{cite book
Line 84: Line 84:
  | first2 = बॉबी | last2 = वूल्फ
  | first2 = बॉबी | last2 = वूल्फ
  | date = 2003
  | date = 2003
  | title = उद्यम एकीकरण पैटर्न: डिजाइनिंग, बिल्डिंग और मैसेजिंग सॉल्यूशंस की तैनाती| publisher = [[एडिसन-वेस्ले]]
  | title = उद्यम एकीकरण पैटर्न: डिजाइनिंग, बिल्डिंग और मैसेजिंग हल की परिनियोजित| publisher = [[एडिसन-वेस्ले]]
  | isbn = 978-0-321-20068-6
  | isbn = 978-0-321-20068-6
| title-link = उद्यम एकीकरण पैटर्न
| title-link = उद्यम एकीकरण पैटर्न
Line 102: Line 102:
  | author-link = क्रेग लर्मन
  | author-link = क्रेग लर्मन
  | year = 2004
  | year = 2004
  | title = यूएमएल और पैटर्न लागू करना (तीसरा संस्करण, पहला संस्करण 1995)| publisher = पियर्सन
  | title = यूएमएल और पैटर्न लागू करना (तीसरा संस्करण, प्रथम संस्करण 1995)| publisher = पियर्सन
  | isbn = 978-0131489066
  | isbn = 978-0131489066
}}
}}
Line 118: Line 118:




== अभ्यास ==
== कार्य ==
डिजाइन पैटर्न परीक्षण किए गए, सिद्ध विकास प्रतिमान प्रदान करके विकास प्रक्रिया को गति दे सकते हैं।<ref>{{cite web
डिजाइन पैटर्न परीक्षण किए गए, सिद्ध विकास प्रतिमान प्रदान करके विकास प्रक्रिया को गति दे सकते हैं।<ref>{{cite web
  | url        = http://msdn.microsoft.com/en-us/vstudio/ff729657
  | url        = http://msdn.microsoft.com/en-us/vstudio/ff729657
Line 126: Line 126:
  | quote      = 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.
  | quote      = 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.
  | access-date = 2012-05-15
  | access-date = 2012-05-15
}}</ref> प्रभावी सॉफ़्टवेयर डिज़ाइन के लिए उन समस्याओं पर विचार करने की आवश्यकता होती है जो बाद में कार्यान्वयन में दिखाई नहीं दे सकते हैं। ताजा लिखे गए कोड में प्रायः छिपे हुए सूक्ष्म समस्याएँ हो सकती हैं जिनका पता लगाने में समय लगता है, ऐसी समस्याएँ जो कभी-कभी सड़क पर बड़ी समस्या उत्पन्न कर सकती हैं। डिज़ाइन पैटर्न का पुन: उपयोग करने से ऐसे सूक्ष्म समस्याओं को रोकने में सहायता मिलती है,<ref>{{cite book |chapter-url=https://books.google.com/books?id=_SklFgSidxQC&q=Reusing+design+patterns+helps+to+prevent+such+subtle+issues&pg=PA636 |page=636|title=Software Applications: Concepts, Methodologies, Tools, and Applications: Concepts, Methodologies, Tools, and Applications|isbn=9781605660615|last1=Tiako|first1=Pierre F.|editor-first1=Pierre F |editor-last1=Tiako |date=31 March 2009 |chapter=Formal Modeling and Specification of Design Patterns Using RTPA |doi=10.4018/978-1-60566-060-8}}</ref> और यह कोडर्स और आर्किटेक्ट्स के लिए कोड पठनीयता में भी सुधार करता है जो पैटर्न से परिचित हैं।
}}</ref> प्रभावी सॉफ़्टवेयर डिज़ाइन के लिए उन समस्याओं पर विचार करने की आवश्यकता होती है जो बाद में कार्यान्वयन में दिखाई नहीं दे सकते हैं। धृष्टतापूर्वक  लिखे गए कोड में प्रायः छिपी हुई जटिल समस्याएँ हो सकती हैं जिनका पता लगाने में समय लगता है, ऐसी समस्याएँ जो कभी-कभी सड़क पर बड़ी समस्या उत्पन्न कर सकती हैं। डिज़ाइन पैटर्न का पुन: उपयोग करने से ऐसे जटिल  समस्याओं को रोकने में सहायता मिलती है,<ref>{{cite book |chapter-url=https://books.google.com/books?id=_SklFgSidxQC&q=Reusing+design+patterns+helps+to+prevent+such+subtle+issues&pg=PA636 |page=636|title=Software Applications: Concepts, Methodologies, Tools, and Applications: Concepts, Methodologies, Tools, and Applications|isbn=9781605660615|last1=Tiako|first1=Pierre F.|editor-first1=Pierre F |editor-last1=Tiako |date=31 March 2009 |chapter=Formal Modeling and Specification of Design Patterns Using RTPA |doi=10.4018/978-1-60566-060-8}}</ref> और यह कोडर्स और स्थापत्य  के लिए कोड पठनीयता में भी सुधार करता है जो पैटर्न से परिचित हैं।


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


परिभाषा के अनुसार, पैटर्न का उपयोग करने वाले प्रत्येक एप्लिकेशन में फिर से प्रोग्राम किया जाना चाहिए। चूंकि कुछ लेखक इसे सॉफ़्टवेयर पुन: उपयोग से एक पश्च चरण के रूप में देखते हैं, जैसा कि सॉफ़्टवेयर घटक द्वारा प्रदान किया गया है, शोधकर्ताओं ने पैटर्न को घटकों में बदलने के लिए काम किया है। मेयर और अर्नौट अपने द्वारा किए गए पैटर्न के दो-तिहाई भाग का पूर्ण या आंशिक घटक प्रदान करने में सक्षम थे।<ref name = "Meyer2006">{{cite journal
परिभाषा के अनुसार, पैटर्न का उपयोग करने वाले प्रत्येक एप्लिकेशन में फिर से प्रोग्राम किया जाना चाहिए। चूंकि कुछ लेखक इसे सॉफ़्टवेयर पुन: उपयोग से एक पश्च चरण के रूप में देखते हैं, जैसा कि सॉफ़्टवेयर घटक द्वारा प्रदान किया गया है, शोधकर्ताओं ने पैटर्न को घटकों में बदलने के लिए काम किया है। मेयर और अर्नौट अपने द्वारा किए गए पैटर्न के दो-तिहाई भाग के पूर्ण या आंशिक घटक प्रदान करने में सक्षम थे।<ref name = "Meyer2006">{{cite journal
  | first1 = Bertrand
  | first1 = Bertrand
  | last1 = Meyer
  | last1 = Meyer
Line 197: Line 197:


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


=== रचनात्मक पैटर्न ===
=== रचनात्मक पैटर्न ===
Line 222: Line 222:
|-
|-
| [[Abstract factory pattern|एब्स्ट्रैक्ट फैक्ट्री]]
| [[Abstract factory pattern|एब्स्ट्रैक्ट फैक्ट्री]]
| विशिष्ट वर्गों को निर्दिष्ट किए बिना संबंधित या आश्रित वस्तुओं के वर्ग बनाने के लिए एक इंटरफ़ेस प्रदान करें।
| विशिष्ट वर्गों को निर्दिष्ट किए बिना संबंधित या आश्रित ऑब्जेक्ट के वर्ग बनाने के लिए एक इंटरफ़ेस प्रदान करें।
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
Line 228: Line 228:
|-
|-
| [[Builder pattern|बिल्डर]]  
| [[Builder pattern|बिल्डर]]  
| एक जटिल वस्तु के निर्माण को उसके अभ्यावेदन से अलग करें, जिससे एक ही निर्माण प्रक्रिया को विभिन्न अभ्यावेदन बनाने की अनुमति मिलती है।
| एक जटिल ऑब्जेक्ट के निर्माण को उसके अभ्यावेदन से अलग करें, जिससे एक ही निर्माण प्रक्रिया को विभिन्न अभ्यावेदन बनाने की अनुमति मिलती है।
| {{yes}}
| {{yes}}
| {{no}}
| {{no}}
Line 234: Line 234:
|-
|-
| [[Dependency injection|डिपेंडेंसी इंजेक्शन]]
| [[Dependency injection|डिपेंडेंसी इंजेक्शन]]
| एक वर्ग वस्तुओं को सीधे बनाने के अतिरिक्त एक इंजेक्टर से आवश्यक वस्तुओं को स्वीकार करता है।
| एक वर्ग ऑब्जेक्ट को सीधे बनाने के अतिरिक्त एक इंजेक्टर से आवश्यक ऑब्जेक्ट को स्वीकार करता है।
| {{no}}
| {{no}}
| {{no}}
| {{no}}
Line 240: Line 240:
|-
|-
| [[Factory method pattern|फैक्टरी विधि]]
| [[Factory method pattern|फैक्टरी विधि]]
| एकल वस्तु बनाने के लिए एक इंटरफ़ेस को परिभाषित करें, परन्तु उपवर्गों को यह निर्धारित  करने दें कि किस वर्ग को तत्काल करना है। फ़ैक्टरी विधि एक वर्ग को उपवर्गों के लिए तात्कालिकता को स्थगित करने देती है।
| एकल ऑब्जेक्ट बनाने के लिए एक इंटरफ़ेस को परिभाषित करें, परन्तु उपवर्गों को यह निर्धारित  करने दें कि किस वर्ग को तत्काल करना है। फ़ैक्टरी विधि एक वर्ग को उपवर्गों के लिए तात्कालिकता को स्थगित करने देती है।
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
Line 246: Line 246:
|-
|-
|  [[Lazy initialization|मन्द आरंभीकरण]]
|  [[Lazy initialization|मन्द आरंभीकरण]]
| किसी वस्तु के निर्माण, किसी मूल्य की गणना, या किसी अन्य महंगी प्रक्रिया में पहली बार आवश्यकता होने तक देरी करने की युक्ति। यह पैटर्न GoF कैटलॉग में "वर्चुअल प्रॉक्सी" के रूप में दिखाई देता है, जो प्रॉक्सी पैटर्न के लिए एक कार्यान्वयन रणनीति है।
| किसी ऑब्जेक्ट के निर्माण, किसी मान की गणना, या किसी अन्य महंगी प्रक्रिया में पहली बार आवश्यकता होने तक देरी करने की युक्ति। यह पैटर्न जीओएफ कैटलॉग में "वास्तविक प्रॉक्सी" के रूप में दिखाई देता है, जो प्रॉक्सी पैटर्न के लिए एक कार्यान्वयन रणनीति है।
| {{no}}
| {{no}}
| {{no}}
| {{no}}
Line 262: Line 262:
|-
|-
| [[Multiton pattern|मल्टीटन]]
| [[Multiton pattern|मल्टीटन]]
| सुनिश्चित करें कि एक वर्ग ने केवल उदाहरणों का नाम दिया है, और उन तक पहुंच का वैश्विक बिंदु प्रदान करें।
| सुनिश्चित करें कि एक वर्ग ने मात्र उदाहरणों का नाम दिया है, और उन तक पहुंच का वैश्विक बिंदु प्रदान करें।
| {{no}}
| {{no}}
| {{no}}
| {{no}}
Line 268: Line 268:
|-
|-
| [[Object pool pattern|ऑब्जेक्ट पूल]]
| [[Object pool pattern|ऑब्जेक्ट पूल]]
| उन वस्तुओं को रिसाइकिल करके महंगे अधिग्रहण और संसाधनों की रिहाई से बचें जो अब उपयोग में नहीं हैं। [[connection pool|संपर्क पूल]]  और [[thread pool|थ्रेड पूल]] पैटर्न का सामान्यीकरण माना जा सकता है।
| उन ऑब्जेक्ट को रिसाइकिल करके महंगे अधिग्रहण और संसाधनों की रिलीज से बचें जो अब उपयोग में नहीं हैं। [[connection pool|संपर्क पूल]]  और [[thread pool|थ्रेड पूल]] पैटर्न का सामान्यीकरण माना जा सकता है।
| {{no}}
| {{no}}
| {{no}}
| {{no}}
Line 274: Line 274:
|-
|-
| [[Prototype pattern|प्रोटोटाइप]]
| [[Prototype pattern|प्रोटोटाइप]]
| एक प्रोटोटाइप उदाहरण का उपयोग करके बनाने के लिए वस्तुओं के प्रकार निर्दिष्ट करें, और वर्तमान ऑब्जेक्ट के 'ढांचे' से नवीन  ऑब्जेक्ट बनाएं, इस प्रकार निष्पादन  को बढ़ावा दें और मेमोरी  फूटप्रिंट्स  को न्यूनतम रखें।
| एक प्रोटोटाइप उदाहरण का उपयोग करके बनाने के लिए ऑब्जेक्ट के प्रकार निर्दिष्ट करें, और वर्तमान ऑब्जेक्ट के 'ढांचे' से नवीन  ऑब्जेक्ट बनाएं, इस प्रकार निष्पादन  को बढ़ावा दें और मेमोरी  फूटप्रिंट्स  को न्यूनतम रखें।
| {{yes}}
| {{yes}}
| {{no}}
| {{no}}
Line 280: Line 280:
|-
|-
| [[Resource Acquisition Is Initialization|संसाधन अधिग्रहण आरंभीकरण है]] (आरएआईआई)
| [[Resource Acquisition Is Initialization|संसाधन अधिग्रहण आरंभीकरण है]] (आरएआईआई)
| सुनिश्चित करें कि संसाधनों को उपयुक्त वस्तुओं के जीवन काल से बांधकर ठीक से जारी किया गया है।
| सुनिश्चित करें कि संसाधनों को उपयुक्त ऑब्जेक्ट के जीवन काल से बांधकर ठीक से जारी किया गया है।
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{n/a}}
| {{n/a}}
|-
|-
| [[Singleton pattern|एकाकी वस्तु]]
| [[Singleton pattern|एकाकी ऑब्जेक्ट]]
| सुनिश्चित करें कि एक वर्ग का केवल एक उदाहरण है, और इसके लिए एक वैश्विक बिंदु प्रदान करें।
| सुनिश्चित करें कि एक वर्ग का मात्र एक उदाहरण है, और इसके लिए एक वैश्विक बिंदु प्रदान करें।
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
Line 303: Line 303:
|-
|-
| [[Adapter pattern|अडैप्टर]], आवरण, या अनुवादक
| [[Adapter pattern|अडैप्टर]], आवरण, या अनुवादक
| एक वर्ग के इंटरफ़ेस को दूसरे इंटरफ़ेस में परिवर्तित करें जिसकी ग्राहक अपेक्षा करते हैं। एडेप्टर कक्षाओं को एक साथ काम करने देता है जो अन्यथा असंगत इंटरफेस के कारण नहीं हो सकता। उद्यम एकीकरण पैटर्न समतुल्य अनुवादक है।
| एक वर्ग के इंटरफ़ेस को दूसरे इंटरफ़ेस में परिवर्तित करें जिसकी क्लाइंट अपेक्षा करते हैं। एडेप्टर कक्षाओं को एक साथ काम करने देता है जो अन्यथा असंगत इंटरफेस के कारण नहीं हो सकता। उद्यम एकीकरण पैटर्न समतुल्य अनुवादक है।
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
Line 315: Line 315:
|-
|-
| [[Composite pattern|कम्पोजिट]]
| [[Composite pattern|कम्पोजिट]]
| आंशिक-संपूर्ण पदानुक्रमों का प्रतिनिधित्व करने के लिए वस्तुओं को वृक्ष संरचनाओं में लिखें। समग्र ग्राहकों को व्यक्तिगत वस्तुओं और वस्तुओं की रचनाओं को समान रूप से व्यवहार करने देता है।
| आंशिक-संपूर्ण पदानुक्रमों का प्रतिनिधित्व करने के लिए ऑब्जेक्ट को ट्री संरचनाओं में लिखें। समग्र क्लाइंटों को विशिष्ट ऑब्जेक्ट और ऑब्जेक्ट की रचनाओं को समान रूप से व्यवहार करने देता है।
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
Line 321: Line 321:
|-
|-
| [[Decorator pattern|डेकोरेटर]]
| [[Decorator pattern|डेकोरेटर]]
| एक ही इंटरफ़ेस को गतिशील रूप से रखते हुए किसी वस्तु को अतिरिक्त ज़िम्मेदारियाँ संलग्न करें। सज्जाकार कार्यक्षमता बढ़ाने के लिए उपवर्गीकरण का एक लचीला विकल्प प्रदान करते हैं।
| एक ही इंटरफ़ेस को गतिशील रूप से रखते हुए किसी ऑब्जेक्ट को अतिरिक्त ज़िम्मेदारियाँ संलग्न करें। डेकोरेटर कार्यक्षमता बढ़ाने के लिए उपवर्गीकरण का एक लचीला विकल्प प्रदान करते हैं।
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
Line 327: Line 327:
|-
|-
| [[Delegation pattern|प्रतिनिधान]]
| [[Delegation pattern|प्रतिनिधान]]
| उपवर्गीकरण के बजाय रचना द्वारा एक वर्ग का विस्तार करें। वस्तु दूसरी वस्तु (प्रतिनिधि) को सौंपकर एक अनुरोध को संभालती है
| उपवर्गीकरण के अतिरिक्त रचना द्वारा एक वर्ग का विस्तार करें। ऑब्जेक्ट दूसरे ऑब्जेक्ट (प्रतिनिधि) को प्रत्यायोजित कर एक अनुरोध को संभालती है
| {{n/a}}
| {{n/a}}
| {{n/a}}
| {{n/a}}
Line 350: Line 350:
|-
|-
| [[Facade pattern|फ़कैड]]
| [[Facade pattern|फ़कैड]]
| सबसिस्टम में इंटरफेस के एक सेट के लिए एक एकीकृत इंटरफ़ेस प्रदान करें। मुखौटा एक उच्च-स्तरीय इंटरफ़ेस को परिभाषित करता है जो सबसिस्टम को उपयोग में आसान बनाता है।
| उपप्रणाली में इंटरफेस के एक समूह  के लिए एक एकीकृत इंटरफ़ेस प्रदान करें। फ़कैड एक उच्च-स्तरीय इंटरफ़ेस को परिभाषित करता है जो उपप्रणाली को उपयोग में सरल  बनाता है।
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
Line 356: Line 356:
|-
|-
| [[Flyweight pattern|फ्लाईवेट]]
| [[Flyweight pattern|फ्लाईवेट]]
| बड़ी संख्या में समान वस्तुओं का कुशलतापूर्वक समर्थन करने के लिए साझाकरण का उपयोग करें।
| बड़ी संख्या में समान ऑब्जेक्ट का दक्षतापूर्वक    सपोर्ट के लिए साझाकरण का उपयोग करें।
| {{yes}}
| {{yes}}
| {{no}}
| {{no}}
Line 392: Line 392:
|-
|-
| [[Marker interface pattern|मार्कर]]
| [[Marker interface pattern|मार्कर]]
| मेटाडेटा को एक वर्ग के साथ जोड़ने के लिए खाली इंटरफ़ेस।
| मेटाडेटा को एक वर्ग के साथ जोड़ने के लिए रिक्त इंटरफ़ेस।
| {{no}}
| {{no}}
| {{no}}
| {{no}}
Line 410: Line 410:
|-
|-
| [[Module pattern|मॉडुल]]
| [[Module pattern|मॉडुल]]
| कई संबंधित तत्वों को समूहित करें, जैसे कि कक्षाएं, सिंगलटन, विधियाँ, विश्व स्तर पर उपयोग की जाने वाली एकल वैचारिक इकाई में।
| कई संबंधित अवयवों को समूहित करें, जैसे कि कक्षाएं, सिंगलटन, विधियाँ, विश्व स्तर पर उपयोग की जाने वाली एकल वैचारिक इकाई में।
| {{no}}
| {{no}}
| {{no}}
| {{no}}
Line 416: Line 416:
|-
|-
| [[Proxy pattern|प्रॉक्सी]]
| [[Proxy pattern|प्रॉक्सी]]
| किसी अन्य वस्तु तक पहुँच को नियंत्रित करने के लिए एक सरोगेट या प्लेसहोल्डर प्रदान करें।
| किसी अन्य ऑब्जेक्ट तक अभिगम को नियंत्रित करने के लिए एक प्रतिनिधि या स्थानधारक प्रदान करें।
| {{yes}}
| {{yes}}
| {{no}}
| {{no}}
Line 422: Line 422:
|-
|-
| [[Twin pattern|ट्विन]]<ref>{{cite web|url=http://www.ssw.jku.at/Research/Papers/Moe99/Paper.pdf |title=Twin – A Design Pattern for Modeling Multiple Inheritance }}</ref>
| [[Twin pattern|ट्विन]]<ref>{{cite web|url=http://www.ssw.jku.at/Research/Papers/Moe99/Paper.pdf |title=Twin – A Design Pattern for Modeling Multiple Inheritance }}</ref>
| ट्विन उन प्रोग्रामिंग भाषाओं में मल्टीपल इनहेरिटेंस के मॉडलिंग की अनुमति देता है जो इस सुविधा का समर्थन नहीं करती हैं।
| ट्विन उन प्रोग्रामिंग भाषाओं में एकाधिक वंशानुक्रम के मॉडलिंग की अनुमति देता है जो इस सुविधा का   सपोर्ट नहीं करती हैं।
| {{no}}
| {{no}}
| {{no}}
| {{no}}
Line 440: Line 440:
|-
|-
| [[Blackboard (design pattern)|ब्लैकबोर्ड]]
| [[Blackboard (design pattern)|ब्लैकबोर्ड]]
| डेटा के असमान स्रोतों के संयोजन के लिए [[Artificial intelligence|कृत्रिम बुद्धिमत्ता]] पैटर्न  ([[blackboard system|ब्लैकबोर्ड सिस्टम]] देखें)
| डेटा के असमान स्रोतों के संयोजन के लिए [[Artificial intelligence|कृत्रिम बुद्धिमत्ता]] पैटर्न  ([[blackboard system|ब्लैकबोर्ड प्रणाली]] देखें)
| {{no}}
| {{no}}
| {{no}}
| {{no}}
Line 446: Line 446:
|-
|-
|  [[Chain-of-responsibility pattern|श्रृंखला का उत्तरदायित्व]]  
|  [[Chain-of-responsibility pattern|श्रृंखला का उत्तरदायित्व]]  
| एक से अधिक वस्तुओं को अनुरोध को संभालने का मौका देकर अनुरोध के प्रेषक को उसके प्राप्तकर्ता के साथ जोड़ने से बचें। रिसीविंग ऑब्जेक्ट्स को चेन करें और चेन के साथ रिक्वेस्ट पास करें जब तक कि कोई ऑब्जेक्ट इसे हैंडल न कर ले।
| एक से अधिक ऑब्जेक्ट को अनुरोध को संभालने का मौका देकर अनुरोध के प्रेषक को उसके प्राप्तकर्ता के साथ जोड़ने से बचें। रिसीविंग ऑब्जेक्ट्स को चेन करें और चेन के साथ रिक्वेस्ट पास करें जब तक कि कोई ऑब्जेक्ट इसे हैंडल न कर ले।
| {{yes}}
| {{yes}}
| {{no}}
| {{no}}
Line 452: Line 452:
|-
|-
| [[Command pattern|कमांड]]
| [[Command pattern|कमांड]]
| एक अनुरोध को एक वस्तु के रूप में समाहित करें, जिससे विभिन्न अनुरोधों वाले ग्राहकों के पैरामीटरकरण और अनुरोधों की कतार या लॉगिंग की अनुमति मिलती है। यह पूर्ववत संचालन के समर्थन के लिए भी अनुमति देता है।
| एक अनुरोध को एक ऑब्जेक्ट के रूप में समाहित करें, जिससे विभिन्न अनुरोधों वाले क्लाइंटों के पैरामीटरकरण और अनुरोधों की कतार या लॉगिंग की अनुमति मिलती है। यह पूर्ववत संचालन के   सपोर्ट के लिए भी अनुमति देता है।
| {{yes}}
| {{yes}}
| {{no}}
| {{no}}
Line 464: Line 464:
|-
|-
| [[Iterator pattern|इटरेटर]]
| [[Iterator pattern|इटरेटर]]
| इसके अंतर्निहित प्रतिनिधित्व को उजागर किए बिना एक [[Aggregate pattern|संयुक्त]] वस्तु के तत्वों को क्रमिक रूप से एक्सेस करने का एक तरीका प्रदान करें।
| इसके अंतर्निहित प्रतिनिधित्व को उजागर किए बिना एक [[Aggregate pattern|संयुक्त]] ऑब्जेक्ट के अवयवों को क्रमिक रूप से एक्सेस करने का एक तरीका प्रदान करें।
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
Line 470: Line 470:
|-
|-
| [[Mediator pattern|मीडिएटर]]  
| [[Mediator pattern|मीडिएटर]]  
| एक वस्तु को परिभाषित करें जो यह बताती है कि वस्तुओं का एक समूह कैसे परस्पर क्रिया करता है। मध्यस्थ वस्तुओं को एक दूसरे से स्पष्ट रूप से संदर्भित करके [[loose coupling|अस्पष्ट युग्मन]]  को बढ़ावा देता है, और यह उनकी बातचीत को स्वतंत्र रूप से भिन्न करने की अनुमति देता है।
| एक ऑब्जेक्ट को परिभाषित करें जो यह बताती है कि ऑब्जेक्ट का एक समूह कैसे परस्पर क्रिया करता है। मध्यस्थ ऑब्जेक्ट को एक दूसरे से स्पष्ट रूप से संदर्भित करके [[loose coupling|अस्पष्ट युग्मन]]  को बढ़ावा देता है, और यह उनकी बातचीत को स्वतंत्र रूप से भिन्न करने की अनुमति देता है।
| {{yes}}
| {{yes}}
| {{no}}
| {{no}}
Line 476: Line 476:
|-
|-
| [[Memento pattern|मोमेंटो]]
| [[Memento pattern|मोमेंटो]]
| एनकैप्सुलेशन का उल्लंघन किए बिना, किसी वस्तु की आंतरिक स्थिति को कैप्चर और बाहरी करें जिससे वस्तु को बाद में इस स्थिति में बहाल किया जा सके।
| एनकैप्सुलेशन का उल्लंघन किए बिना, किसी ऑब्जेक्ट की आंतरिक स्थिति को कैप्चर और बाहरी करें जिससे ऑब्जेक्ट को बाद में इस स्थिति में बहाल किया जा सके।
| {{yes}}
| {{yes}}
| {{no}}
| {{no}}
| {{n/a}}
| {{n/a}}
|-
|-
| [[Null Object pattern|अशक्त वस्तु]]
| [[Null Object pattern|अशक्त ऑब्जेक्ट]]
| एक डिफ़ॉल्ट वस्तु प्रदान करके अशक्त संदर्भों से बचें।
| एक डिफ़ॉल्ट ऑब्जेक्ट प्रदान करके अशक्त संदर्भों से बचें।
| {{no}}
| {{no}}
| {{no}}
| {{no}}
Line 488: Line 488:
|-
|-
| [[Observer pattern|समीक्षक]] या [[Publish/subscribe|प्रकाशित/सदस्यता]]
| [[Observer pattern|समीक्षक]] या [[Publish/subscribe|प्रकाशित/सदस्यता]]
| वस्तुओं के बीच एक-से-कई निर्भरता को परिभाषित करें जहां एक वस्तु में राज्य परिवर्तन के परिणामस्वरूप उसके सभी आश्रितों को स्वचालित रूप से अधिसूचित और अद्यतन किया जाता है।
| ऑब्जेक्ट के बीच एक-से-कई निर्भरता को परिभाषित करें जहां एक ऑब्जेक्ट में राज्य परिवर्तन के परिणामस्वरूप उसके सभी आश्रितों को स्वचालित रूप से अधिसूचित और अद्यतन किया जाता है।
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
Line 494: Line 494:
|-
|-
| [[Design pattern Servant|सर्वेंट]]
| [[Design pattern Servant|सर्वेंट]]
| वर्गों के एक समूह के लिए सामान्य कार्यक्षमता को परिभाषित करें। नौकर पैटर्न को अक्सर वर्गों के दिए गए सेट के लिए सहायक वर्ग या उपयोगिता वर्ग कार्यान्वयन भी कहा जाता है। सहायक वर्गों के पास आम तौर पर कोई वस्तु नहीं होती है इसलिए उनके पास सभी स्थिर तरीके होते हैं जो विभिन्न प्रकार की कक्षा वस्तुओं पर कार्य करते हैं।
| वर्गों के एक समूह के लिए सामान्य कार्यक्षमता को परिभाषित करें। नौकर पैटर्न को अक्सर वर्गों के दिए गए समूह  के लिए सहायक वर्ग या उपयोगिता वर्ग कार्यान्वयन भी कहा जाता है। सहायक वर्गों के पास आम तौर पर कोई ऑब्जेक्ट नहीं होती है इसलिए उनके पास सभी स्थिर तरीके होते हैं जो विभिन्न प्रकार की कक्षा ऑब्जेक्ट पर कार्य करते हैं।
| {{no}}
| {{no}}
| {{no}}
| {{no}}
Line 506: Line 506:
|-
|-
|  [[State pattern|स्थिति]]
|  [[State pattern|स्थिति]]
| जब किसी वस्तु की आंतरिक स्थिति बदलती है तो उसे अपने व्यवहार को बदलने की अनुमति दें। वस्तु अपनी कक्षा बदलती प्रतीत होगी।
| जब किसी ऑब्जेक्ट की आंतरिक स्थिति बदलती है तो उसे अपने व्यवहार को बदलने की अनुमति दें। ऑब्जेक्ट अपनी कक्षा बदलती प्रतीत होगी।
| {{yes}}
| {{yes}}
| {{no}}
| {{no}}
Line 512: Line 512:
|-
|-
| [[Strategy pattern|रणनीति]]
| [[Strategy pattern|रणनीति]]
| एल्गोरिदम के एक परिवार को परिभाषित करें, प्रत्येक को इनकैप्सुलेट करें और उन्हें विनिमेय बनाएं। रणनीति एल्गोरिथम का उपयोग करने वाले ग्राहकों से स्वतंत्र रूप से भिन्न होने देती है।
| एल्गोरिदम के एक परिवार को परिभाषित करें, प्रत्येक को इनकैप्सुलेट करें और उन्हें विनिमेय बनाएं। रणनीति एल्गोरिथम का उपयोग करने वाले क्लाइंटों से स्वतंत्र रूप से भिन्न होने देती है।
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
Line 524: Line 524:
|-
|-
| [[Visitor pattern|आगंतुक]]
| [[Visitor pattern|आगंतुक]]
| कक्षाओं के एक सेट के उदाहरणों पर किए जाने वाले ऑपरेशन का प्रतिनिधित्व करें। विज़िटर उन तत्वों के वर्गों को बदले बिना एक नए ऑपरेशन को परिभाषित करने देता है जिन पर वह संचालित होता है।
| कक्षाओं के एक समूह  के उदाहरणों पर किए जाने वाले ऑपरेशन का प्रतिनिधित्व करें। विज़िटर उन अवयवों के वर्गों को बदले बिना एक नए ऑपरेशन को परिभाषित करने देता है जिन पर वह संचालित होता है।
| {{yes}}
| {{yes}}
| {{no}}
| {{no}}
Line 559: Line 559:
|-
|-
| [[Balking pattern|Balking]]
| [[Balking pattern|Balking]]
| किसी वस्तु पर केवल तभी क्रिया निष्पादित करें जब वस्तु किसी विशेष अवस्था में हो।
| किसी ऑब्जेक्ट पर मात्र तभी क्रिया निष्पादित करें जब ऑब्जेक्ट किसी विशेष अवस्था में हो।
| {{no}}
| {{no}}
| {{n/a}}
| {{n/a}}
|-
|-
| [[Binding properties pattern|Binding properties]]
| [[Binding properties pattern|Binding properties]]
| विभिन्न वस्तुओं में गुणों को किसी तरह से सिंक्रनाइज़ या समन्वित करने के लिए कई पर्यवेक्षकों का संयोजन।<ref>[http://c2.com/cgi/wiki?BindingProperties Binding Properties<!-- Bot generated title -->]</ref>
| विभिन्न ऑब्जेक्ट में गुणों को किसी तरह से सिंक्रनाइज़ या समन्वित करने के लिए कई पर्यवेक्षकों का संयोजन।<ref>[http://c2.com/cgi/wiki?BindingProperties Binding Properties<!-- Bot generated title -->]</ref>
| {{no}}
| {{no}}
| {{n/a}}
| {{n/a}}
Line 574: Line 574:
|-
|-
| [[Double checked locking pattern|Double-checked locking]]
| [[Double checked locking pattern|Double-checked locking]]
| पहले लॉकिंग मानदंड ('लॉक हिंट') का असुरक्षित तरीके से परीक्षण करके लॉक प्राप्त करने के ओवरहेड को कम करें; केवल अगर यह सफल होता है तो वास्तविक लॉकिंग लॉजिक आगे बढ़ता है।
| पहले लॉकिंग मानदंड ('लॉक हिंट') का असुरक्षित तरीके से परीक्षण करके लॉक प्राप्त करने के ओवरहेड को कम करें; मात्र अगर यह सफल होता है तो वास्तविक लॉकिंग लॉजिक आगे बढ़ता है।
कुछ भाषा/हार्डवेयर संयोजनों में कार्यान्वित किए जाने पर असुरक्षित हो सकता है। इसलिए इसे कभी-कभी एक [[anti-pattern|विरोधी पैटर्न]]  माना जा सकता है।
कुछ भाषा/हार्डवेयर संयोजनों में कार्यान्वित किए जाने पर असुरक्षित हो सकता है। इसलिए इसे कभी-कभी एक [[anti-pattern|विरोधी पैटर्न]]  माना जा सकता है।
| {{yes}}
| {{yes}}
Line 605: Line 605:
|-
|-
| [[Monitor (synchronization)|Monitor object]]
| [[Monitor (synchronization)|Monitor object]]
| एक वस्तु जिसके तरीके [[mutual exclusion|परस्पर बहिष्करण]] के अधीन हैं, इस प्रकार एक ही समय में कई वस्तुओं को गलत तरीके से इसका उपयोग करने से रोकते हैं।
| एक ऑब्जेक्ट जिसके तरीके [[mutual exclusion|परस्पर बहिष्करण]] के अधीन हैं, इस प्रकार एक ही समय में कई ऑब्जेक्ट को गलत तरीके से इसका उपयोग करने से रोकते हैं।
| {{yes}}
| {{yes}}
| {{n/a}}
| {{n/a}}
Line 615: Line 615:
|-
|-
| [[Read/write lock pattern|Read-write lock]]
| [[Read/write lock pattern|Read-write lock]]
| एक वस्तु के लिए समवर्ती पठन पहुँच की अनुमति देता है, लेकिन लेखन कार्यों के लिए विशेष पहुँच की आवश्यकता होती है। लिखने के लिए एक अंतर्निहित सेमाफोर का उपयोग किया जा सकता है, और [[copy-on-write|कॉपी-ऑन-राइट]]  तंत्र का उपयोग किया जा सकता है या नहीं भी किया जा सकता है।
| एक ऑब्जेक्ट के लिए समवर्ती पठन अभिगम की अनुमति देता है, लेकिन लेखन कार्यों के लिए विशेष अभिगम की आवश्यकता होती है। लिखने के लिए एक अंतर्निहित सेमाफोर का उपयोग किया जा सकता है, और [[copy-on-write|कॉपी-ऑन-राइट]]  तंत्र का उपयोग किया जा सकता है या नहीं भी किया जा सकता है।
| {{no}}
| {{no}}
| {{n/a}}
| {{n/a}}
|-
|-
| [[Scheduler pattern|Scheduler]]
| [[Scheduler pattern|Scheduler]]
| Explicitly control when threads may execute single-threaded code.
| स्पष्ट रूप से नियंत्रित करें जब थ्रेड्स एकल-थ्रेडेड कोड निष्पादित कर सकते हैं।
| {{no}}
| {{no}}
| {{n/a}}
| {{n/a}}
|-
|-
| [[Thread pool pattern|Thread pool]]
| [[Thread pool pattern|Thread pool]]
| A number of threads are created to perform a number of tasks, which are usually organized in a queue. Typically, there are many more tasks than threads. Can be considered a special case of the [[object pool]] pattern.
| कई कार्यों को करने के लिए कई थ्रेड्स बनाए जाते हैं, जो आमतौर पर एक कतार में व्यवस्थित होते हैं। आमतौर पर, थ्रेड्स की तुलना में बहुत अधिक कार्य होते हैं।  [[object pool|ऑब्जेक्ट पूल]] पैटर्न का एक विशेष मामला माना जा सकता है।
| {{no}}
| {{no}}
| {{n/a}}
| {{n/a}}
|-
|-
| [[Thread-Specific Storage|Thread-specific storage]]
| [[Thread-Specific Storage|Thread-specific storage]]
| Static or "global" memory local to a thread.
| थ्रेड के लिए स्थिर या "वैश्विक" मेमोरी स्थानीय।
| {{yes}}
| {{yes}}
| {{n/a}}
| {{n/a}}
|-
|-
| Safe Concurrency with Exclusive Ownership
| Safe Concurrency with Exclusive Ownership
| Avoiding the need for runtime concurrent mechanisms, because exclusive ownership can be proven. This is a notable capability of the Rust language, but compile-time checking isn't the only means, a programmer will often manually design such patterns into code - omitting the use of locking mechanism because the programmer assesses that a given variable is never going to be concurrently accessed.
| रनटाइम समवर्ती तंत्र की आवश्यकता से बचना, क्योंकि अनन्य स्वामित्व सिद्ध किया जा सकता है। यह रस्ट लैंग्वेज की एक उल्लेखनीय क्षमता है, लेकिन कंपाइल-टाइम चेकिंग एकमात्र साधन नहीं है, एक प्रोग्रामर अक्सर ऐसे पैटर्न को कोड में मैन्युअल रूप से डिज़ाइन करेगा - लॉकिंग मैकेनिज्म के उपयोग को छोड़ देगा क्योंकि प्रोग्रामर का आकलन है कि एक दिया गया चर कभी नहीं जा रहा है एक साथ अभिगमा जा सकता है।
| {{no}}
| {{no}}
| {{n/a}}
| {{n/a}}
|-
|-
| CPU atomic operation
| CPU atomic operation
| x86 and other CPU architectures support a range of atomic instructions that guarantee memory safety for modifying and accessing primitive values (integers). For example, two threads may both increment a counter safely. These capabilities can also be used to implement the mechanisms for other concurrency patterns as above. The [[C Sharp (programming language)|C#]] language uses the [https://docs.microsoft.com/en-us/dotnet/api/system.threading.interlocked?view=net-5.0 Interlocked] class for these capabilities.
| x86 और अन्य सीपीयू आर्किटेक्चर परमाणु निर्देशों की एक श्रृंखला का  सपोर्ट करते हैं जो आदिम मानों (पूर्णांक) को संशोधित करने और एक्सेस करने के लिए मेमोरी सुरक्षा की गारंटी देते हैं। उदाहरण के लिए, दो धागे काउंटर को सुरक्षित रूप से बढ़ा सकते हैं। इन क्षमताओं का उपयोग उपरोक्त के रूप में अन्य समवर्ती पैटर्न के तंत्र को लागू करने के लिए भी किया जा सकता है। [[C Sharp (programming language)|C#]] भाषा इन क्षमताओं के लिए [https://docs.microsoft.com/en-us/dotnet/api/system.threading.interlocked?view=net-5.0 इंटरलाक्ड] क्लास का उपयोग करती है।
| {{no}}
| {{no}}
| {{n/a}}
| {{n/a}}
Line 670: Line 670:
*'प्रयोज्यता:' जिन स्थितियों में यह पैटर्न प्रयोग करने योग्य है; पैटर्न के लिए संदर्भ।
*'प्रयोज्यता:' जिन स्थितियों में यह पैटर्न प्रयोग करने योग्य है; पैटर्न के लिए संदर्भ।
*'संरचना:' पैटर्न का एक चित्रमय प्रतिनिधित्व। इस उद्देश्य के लिए यूनिफाइड मॉडलिंग लैंग्वेज#UML क्लास डायग्राम और [[ इंटरेक्शन आरेख |इंटरेक्शन आरेख]] का इस्तेमाल किया जा सकता है।
*'संरचना:' पैटर्न का एक चित्रमय प्रतिनिधित्व। इस उद्देश्य के लिए यूनिफाइड मॉडलिंग लैंग्वेज#UML क्लास डायग्राम और [[ इंटरेक्शन आरेख |इंटरेक्शन आरेख]] का इस्तेमाल किया जा सकता है।
*'प्रतिभागी:' पैटर्न में उपयोग की जाने वाली कक्षाओं और वस्तुओं की सूची और डिजाइन में उनकी भूमिका।
*'प्रतिभागी:' पैटर्न में उपयोग की जाने वाली कक्षाओं और ऑब्जेक्ट की सूची और डिजाइन में उनकी भूमिका।
*'सहयोग:' पैटर्न में उपयोग की जाने वाली कक्षाएं और ऑब्जेक्ट एक दूसरे के साथ कैसे इंटरैक्ट करते हैं, इसका विवरण।
*'सहयोग:' पैटर्न में उपयोग की जाने वाली कक्षाएं और ऑब्जेक्ट एक दूसरे के साथ कैसे इंटरैक्ट करते हैं, इसका विवरण।
*'परिणाम:' पैटर्न का उपयोग करने के कारण होने वाले परिणामों, साइड इफेक्ट्स और ट्रेड ऑफ का विवरण।
*'परिणाम:' पैटर्न का उपयोग करने के कारण होने वाले परिणामों, साइड इफेक्ट्स और ट्रेड ऑफ का विवरण।
Line 679: Line 679:


== आलोचना ==
== आलोचना ==
यह देखा गया है कि डिज़ाइन पैटर्न केवल एक संकेत हो सकता है कि किसी दी गई प्रोग्रामिंग भाषा (उदाहरण के लिए [[जावा (प्रोग्रामिंग भाषा)]] या C ++) में कुछ सुविधाएँ गायब हैं। [[पीटर नॉरविग]] दर्शाता है कि डिज़ाइन पैटर्न पुस्तक (जो मुख्य रूप से [[सी ++]] पर केंद्रित है) में 23 में से 16 पैटर्न [[लिस्प (प्रोग्रामिंग भाषा)]] या [[डायलन (प्रोग्रामिंग भाषा)]] में सरलीकृत या समाप्त (प्रत्यक्ष भाषा सपोर्ट के माध्यम से) हैं।<ref name="Norvig1998">{{cite conference
यह देखा गया है कि डिज़ाइन पैटर्न मात्र एक संकेत हो सकता है कि किसी दी गई प्रोग्रामिंग भाषा (उदाहरण के लिए [[जावा (प्रोग्रामिंग भाषा)]] या C ++) में कुछ सुविधाएँ गायब हैं। [[पीटर नॉरविग]] दर्शाता है कि डिज़ाइन पैटर्न पुस्तक (जो मुख्य रूप से [[सी ++]] पर केंद्रित है) में 23 में से 16 पैटर्न [[लिस्प (प्रोग्रामिंग भाषा)]] या [[डायलन (प्रोग्रामिंग भाषा)]] में सरलीकृत या समाप्त (प्रत्यक्ष भाषा सपोर्ट के माध्यम से) हैं।<ref name="Norvig1998">{{cite conference
  | last = Norvig
  | last = Norvig
  | first = Peter
  | first = Peter

Revision as of 20:21, 9 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] अन्य
Active Object मेथड एक्जीक्यूशन को मेथड इन्वोकेशन से अलग करता है जो उनके अपने नियंत्रण के थ्रेड में रहता है। लक्ष्य एसिंक्रोनस विधि आमंत्रण और अनुरोधों को संभालने के लिए शेड्यूलर का उपयोग करके समवर्तीता पेश करना है। Yes —
Balking किसी ऑब्जेक्ट पर मात्र तभी क्रिया निष्पादित करें जब ऑब्जेक्ट किसी विशेष अवस्था में हो। No —
Binding properties विभिन्न ऑब्जेक्ट में गुणों को किसी तरह से सिंक्रनाइज़ या समन्वित करने के लिए कई पर्यवेक्षकों का संयोजन।[22] No —
Compute kernel समानांतर में एक ही गणना कई बार, गैर-ब्रांचिंग पॉइंटर गणित के साथ उपयोग किए जाने वाले पूर्णांक मापदंडों द्वारा साझा सरणियों में भिन्न होती है, जैसे कि जीपीयू-अनुकूलित मैट्रिक्स गुणन या कनवॉल्यूशनल न्यूरल नेटवर्क। No —
Double-checked locking पहले लॉकिंग मानदंड ('लॉक हिंट') का असुरक्षित तरीके से परीक्षण करके लॉक प्राप्त करने के ओवरहेड को कम करें; मात्र अगर यह सफल होता है तो वास्तविक लॉकिंग लॉजिक आगे बढ़ता है।

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

Yes —
Event-based asynchronous मल्टीथ्रेडेड प्रोग्राम में होने वाले अतुल्यकालिक पैटर्न के साथ समस्याओं का समाधान करता है।[23] No —
Guarded suspension संचालन का प्रबंधन करता है जिसके लिए लॉक को अधिग्रहित करने की आवश्यकता होती है और ऑपरेशन को निष्पादित करने से पहले संतुष्ट होने की पूर्व शर्त होती है। No —
Join जॉइन-पैटर्न संदेश पास करके समवर्ती, समानांतर और वितरित प्रोग्राम लिखने का एक तरीका प्रदान करता है। थ्रेड्स और लॉक्स के उपयोग की तुलना में, यह एक उच्च-स्तरीय प्रोग्रामिंग मॉडल है। No —
Lock एक थ्रेड संसाधन पर "लॉक" लगाता है, अन्य थ्रेड्स को इसे एक्सेस करने या संशोधित करने से रोकता है।[24] No PoEAA[15]
Messaging design pattern (MDP) घटकों और अनुप्रयोगों के बीच सूचनाओं (यानी संदेशों) के आदान-प्रदान की अनुमति देता है। No —
Monitor object एक ऑब्जेक्ट जिसके तरीके परस्पर बहिष्करण के अधीन हैं, इस प्रकार एक ही समय में कई ऑब्जेक्ट को गलत तरीके से इसका उपयोग करने से रोकते हैं। Yes —
Reactor एक रिएक्टर ऑब्जेक्ट संसाधनों के लिए एक अतुल्यकालिक इंटरफ़ेस प्रदान करता है जिसे तुल्यकालिक रूप से नियंत्रित किया जाना चाहिए। Yes —
Read-write lock एक ऑब्जेक्ट के लिए समवर्ती पठन अभिगम की अनुमति देता है, लेकिन लेखन कार्यों के लिए विशेष अभिगम की आवश्यकता होती है। लिखने के लिए एक अंतर्निहित सेमाफोर का उपयोग किया जा सकता है, और कॉपी-ऑन-राइट तंत्र का उपयोग किया जा सकता है या नहीं भी किया जा सकता है। No —
Scheduler स्पष्ट रूप से नियंत्रित करें जब थ्रेड्स एकल-थ्रेडेड कोड निष्पादित कर सकते हैं। No —
Thread pool कई कार्यों को करने के लिए कई थ्रेड्स बनाए जाते हैं, जो आमतौर पर एक कतार में व्यवस्थित होते हैं। आमतौर पर, थ्रेड्स की तुलना में बहुत अधिक कार्य होते हैं। ऑब्जेक्ट पूल पैटर्न का एक विशेष मामला माना जा सकता है। No —
Thread-specific storage थ्रेड के लिए स्थिर या "वैश्विक" मेमोरी स्थानीय। Yes —
Safe Concurrency with Exclusive Ownership रनटाइम समवर्ती तंत्र की आवश्यकता से बचना, क्योंकि अनन्य स्वामित्व सिद्ध किया जा सकता है। यह रस्ट लैंग्वेज की एक उल्लेखनीय क्षमता है, लेकिन कंपाइल-टाइम चेकिंग एकमात्र साधन नहीं है, एक प्रोग्रामर अक्सर ऐसे पैटर्न को कोड में मैन्युअल रूप से डिज़ाइन करेगा - लॉकिंग मैकेनिज्म के उपयोग को छोड़ देगा क्योंकि प्रोग्रामर का आकलन है कि एक दिया गया चर कभी नहीं जा रहा है एक साथ अभिगमा जा सकता है। No —
CPU atomic operation x86 और अन्य सीपीयू आर्किटेक्चर परमाणु निर्देशों की एक श्रृंखला का सपोर्ट करते हैं जो आदिम मानों (पूर्णांक) को संशोधित करने और एक्सेस करने के लिए मेमोरी सुरक्षा की गारंटी देते हैं। उदाहरण के लिए, दो धागे काउंटर को सुरक्षित रूप से बढ़ा सकते हैं। इन क्षमताओं का उपयोग उपरोक्त के रूप में अन्य समवर्ती पैटर्न के तंत्र को लागू करने के लिए भी किया जा सकता है। C# भाषा इन क्षमताओं के लिए इंटरलाक्ड क्लास का उपयोग करती है। No —


प्रलेखन

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

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

आलोचना

यह देखा गया है कि डिज़ाइन पैटर्न मात्र एक संकेत हो सकता है कि किसी दी गई प्रोग्रामिंग भाषा (उदाहरण के लिए जावा (प्रोग्रामिंग भाषा) या 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=110731’