डिज़ाइन पैटर्न (कंप्यूटर विज्ञान)

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

डिज़ाइन पैटर्न, मॉड्यूल और इंटरकनेक्शन के प्रभाव क्षेत्र में रहते हैं. उच्च स्तर पर, ऐसे वास्तुकला पैटर्न मौजूद होते हैं, जिनका विस्तार अपेक्षाकृत बड़ा होता हैं, जो आम तौर पर एक पूरी प्रणाली द्वारा अनुसरण किए जाने वाले एक समग्र पैटर्न का वर्णन करते हैं.

सभी सॉफ्टवेयर पैटर्न, डिज़ाइन पैटर्न नहीं होते. उदाहरण के लिए, कलनविधि, सॉफ्टवेयर डिज़ाइन समस्याओं के बजाय परिकलन समस्याओं को सुलझाता है.

इतिहास

पैटर्न, क्रिस्टोफर एलेक्ज़ांडर (1977/79) द्वारा एक वास्तुकला अवधारणा के रूप में उत्पन्न हुए. 1987 में, केंट बैक और वार्ड कनिंघम ने प्रोग्रामिंग पर पैटर्न लागू करने के विचार के साथ प्रयोग शुरू किया और उस वर्ष OOPSLA सम्मेलन में अपने परिणाम प्रस्तुत किये. बाद के वर्षों में, बेक, कनिंघम और दूसरों ने इस पर काम करना जारी रखा.

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

• Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. आई॰ऍस॰बी॰ऍन॰ 0-201-63361-2. 
• Schmidt, Douglas C.; Michael Stal, Hans Rohnert, Frank Buschmann (2000). Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects. John Wiley & Sons. आई॰ऍस॰बी॰ऍन॰ 0-471-60695-2. 
• Fowler, Martin (2002). Patterns of Enterprise Application Architecture. Addison-Wesley. आई॰ऍस॰बी॰ऍन॰ 978-0321127426. 
• Hohpe, Gregor; Bobby Woolf (2003). Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley. आई॰ऍस॰बी॰ऍन॰ 0-321-20068-3. 

हालांकि डिज़ाइन पैटर्न का व्यावहारिक अनुप्रयोग एक तथ्य है, तथापि डिज़ाइन पैटर्न की अवधारणा को नियमनिष्ठ करने का कार्य कई वर्षों तक अटका रहा.

अभ्यास

डिज़ाइन पैटर्न, विकास प्रक्रिया को सिद्ध और परखे हुए विकास मानदंड प्रदान करते हुए तेज़ कर सकता है. प्रभावी सॉफ्टवेयर डिज़ाइन में उन मुद्दों पर विचार करने की आवश्यकता होती है, जो कार्यान्वयन में बाद तक दिखाई नहीं दे सकते हैं. डिज़ाइन पैटर्न का पुनर्प्रयोग कुछ सूक्ष्म मुद्दों को रोकने में मदद करता है, जो व्यापक समस्या पैदा कर सकते हैं, और यह कोड लिखने वालों और वास्तुकारों के लिए, जो पैटर्न से परिचित हैं, कोड पठनीयता में सुधार करता है.

लचीलापन प्राप्त करने के लिए, डिज़ाइन पैटर्न आम तौर पर परोक्ष उपाय का अतिरिक्त स्तर पेश करते हैं, जो कुछ मामलों में परिणामी डिज़ाइन को जटिल और अनुप्रयोग प्रदर्शन को चोट पहुंचा सकते हैं.

परिभाषा के अनुसार, एक पैटर्न का उसका उपयोग करने वाले प्रत्येक अनुप्रयोग में नए सिरे से प्रोग्रामिंग किया जाना चाहिए. चूंकि कुछ लेखक इसे घटकों द्वारा उपलब्ध कराए गए अनुसार सॉफ्टवेयर पुनःप्रयोग से एक पिछड़े कदम के रूप में देखते हैं, शोधकर्ताओं ने पैटर्न को घटकों में बदलने के लिए काम किया. मेयेर और अर्नोट, सर्वाधिक ज्ञात पैटर्न को घटक में परिवर्तित करने में दो तिहाई सफलता दर का दावा करते हैं.

अक्सर लोग, कुछ सॉफ्टवेयर डिज़ाइन तकनीकों को कुछ समस्याओं के लिए कैसे लागू करें, बस इतना ही समझते हैं.^{[कृपया उद्धरण जोड़ें]} इन तकनीकों को समस्याओं की एक व्यापक श्रेणी के लिए लागू करना कठिन है. डिज़ाइन पैटर्न सामान्य समाधान प्रदान करते हैं, जो एक ऐसे प्रारूप में प्रलेखित होता है, जिसे किसी विशिष्ट समस्या से बंधे विनिर्देशन की आवश्यकता नहीं होती है.

संरचना

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

इसके अतिरिक्त, पैटर्न, डेवलपर्स को सॉफ्टवेयर की परस्पर क्रिया के लिए अच्छी तरह से ज्ञात, अच्छी तरह से समझे हुए नाम के प्रयोग से संवाद करने की अनुमति देते हैं. आम डिज़ाइन पैटर्न को अस्थाई डिज़ाइन से अधिक मजबूत बनाते हुए, समय के साथ सुधारा जा सकता है.

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

डिज़ाइन पैटर्न को विशेष डोमेन में कोडबद्ध करने के प्रयास भी किये गए हैं, जिसमें वर्तमान डिज़ाइन पैटर्न के उपयोग सहित डोमेन विशिष्ट डिज़ाइन पैटर्न शामिल है. उदाहरणों में शामिल हैं प्रयोक्ता अंतरफलक डिज़ाइन पैटर्न, सूचना विज़ुअलाइज़ेशन, "सुरक्षित प्रयोज्यता" और वेब डिज़ाइन.

वार्षिक पैटर्न लैंग्वेजेस ऑफ़ प्रोग्रामिंग सम्मेलन की कार्यवाही में डोमेन विशेष पैटर्न के कई उदाहरण शामिल हैं.

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

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

नाम	विवरण	डिज़ाइन पैटर्न में	कोड कंप्लीट में	POSA2 में	PoEAA में
क्रिएशनल पैटर्न
एब्सट्रैक्ट फैक्ट्री	संबंधित या निर्भर ऑब्जेक्ट के परिवारों को बनाने के लिए, उनके ठोस वर्ग को निर्दिष्ट किये बिना एक इंटरफेस प्रदान करते हैं.	हाँ	हाँ	नहीं	नहीं
फैक्टरी विधि	ऑब्जेक्ट निर्माण के लिए एक इंटरफेस को परिभाषित करते हैं, लेकिन उपवर्गों को निर्णय लेने देते हैं कि किस वर्ग का दृष्टांत देना है. फैक्टरी विधि एक वर्ग को उपवर्गों में सोदाहरण प्रस्तुति टालने देती है	हाँ	हाँ	नहीं	नहीं
बिल्डर	एक जटिल ऑब्जेक्ट के निर्माण को इसके प्रतिनिधित्व से अलग करें, ताकि एक ही निर्माण प्रक्रिया अलग-अलग प्रतिनिधित्व तैयार कर सके.	हाँ	नहीं	नहीं	नहीं
लेज़ी इनिश्यलाईजेशन	एक ऑब्जेक्ट के निर्माण में देरी की चाल, पहली बार जरूरत पड़ने तक एक मूल्य, या किसी अन्य महंगी प्रक्रिया की गणना.	नहीं	नहीं	नहीं	हाँ
ऑब्जेक्ट पूल	महंगे अधिग्रहण का परिहार और अप्रयुक्त ऑब्जेक्ट के पुनर्निवेश द्वारा संसाधनों को जारी करना.	नहीं	नहीं	नहीं	नहीं
प्रोटोटाइप	प्रोटोटाइप उदाहरण का उपयोग करते हुए निर्मित किए जाने वाले ऑब्जेक्ट के प्रकार को निर्दिष्ट करते हैं, और इस प्रोटोटाइप को कॉपी करते हुए नए ऑब्जेक्ट तैयार करते हैं.	हाँ	नहीं	नहीं	नहीं
सिंगलटन	सुनिश्चित करते हैं कि एक वर्ग का केवल एक उदाहरण है, और उस तक पहुंचने के लिए एक वैश्विक बिंदु उपलब्ध कराते हैं.	हाँ	हाँ	नहीं	नहीं
मल्टीटन	सुनिश्चित करते हैं कि एक वर्ग के पास केवल नामोद्दिष्ट उदाहरण हैं, और उन तक पहुंचने के लिए एक वैश्विक बिंदु प्रदान करते हैं.	नहीं	नहीं	नहीं	नहीं
संसाधन अधिग्रहण प्रारंभ करना है	संसाधनों को उपयुक्त ऑब्जेक्ट के जीवनकाल से जोडते हुए, सुनिश्चित करते हैं कि उन्हें अच्छी तरह से जारी किया गया है.	नहीं	नहीं	नहीं	नहीं
स्ट्रक्चरल पैटर्न
अडैप्टर या रैपर	एक वर्ग के इंटरफेस को क्लाइंट की अपेक्षा के अनुरूप दूसरे इंटरफ़ेस में बदलते हैं. अडैप्टर, वर्गों को एक साथ काम करने देता है, जो अन्यथा असंगत इंटरफेस की वजह से कर नहीं पाते.	हाँ	हाँ	नहीं	नहीं
ब्रिड्ज	एक एब्स्ट्रेक्शन को उसके कार्यान्वयन से विसंबंधित करते हैं, ताकि दोनों स्वतंत्र रूप से भिन्न हो सकें.	हाँ	हाँ	नहीं	नहीं
कॉम्पोज़िट	आंशिक-संपूर्ण ढांचे को दर्शाने के लिए, वृक्ष संरचना में ऑब्जेक्ट का गठन करते हैं. कॉम्पोज़िट, एकल ऑब्जेक्ट और ऑब्जेक्ट की संरचनाओं को समान रूप से व्यवहार करने के लिए क्लाइंट की मदद करते हैं.	हाँ	हाँ	नहीं	नहीं
डेकोरेटर	समान इंटरफ़ेस रखते हुए गतिशील रूप से एक ऑब्जेक्ट से अतिरिक्त जिम्मेदारी जोड़ते हैं. डेकोरेटर कार्यक्षमता बढ़ाने के लिए उपवर्गीकरण का लचीला विकल्प प्रदान करते हैं.	हाँ	हाँ	नहीं	नहीं
फसाड	एक उपतंत्र में इंटरफेस के एक सेट के लिए एकीकृत इंटरफेस प्रदान करते हैं. फसाड, एक उच्च स्तरीय इंटरफेस को परिभाषित करता है, जो उपतंत्र के उपयोग को आसान बना देता है.	हाँ	हाँ	नहीं	नहीं
फ्लाईवेट	बड़ी संख्या में फाइन-ग्रेन्ड ऑब्जेक्ट को कुशलता से समर्थन देने के लिए शेयरिंग का प्रयोग करता है.	हाँ	नहीं	नहीं	नहीं
प्रॉक्सी	अपने अभिगम को नियंत्रित करने हेतु, एक अन्य ऑब्जेक्ट के लिए एक सरोगेट या प्लेसहोल्डर प्रदान करता है.	हाँ	नहीं	नहीं	नहीं
बिहेवीयरल पैटर्न
चेन ऑफ़ रेस्पोंसिबिलिटी	एक से अधिक ऑब्जेक्ट को अनुरोध संभालने का मौका देकर, एक अनुरोध भेजने वाले का उसके प्राप्तकर्ता से विसंबंधन होने से बचाता है.प्राप्त ऑब्जेक्ट को श्रृंखला में जोड़ता है और अनुरोध को श्रृंखला के साथ आगे बढ़ाता है, जब तक कि एक ऑब्जेक्ट उसे नहीं संभाल लेता.	हाँ	नहीं	नहीं	नहीं
कमांड	एक अनुरोध को एक ऑब्जेक्ट के रूप में आवेष्टित करता है, जिससे आप क्लाइंट को अलग-अलग अनुरोधों से प्राचलों में वर्णित कर सकें, अनुरोध को पंक्तिबद्ध या लॉग कर सकें, और कठिन संक्रियाओं का समर्थन कर सकें.	हाँ	नहीं	नहीं	नहीं
इंटरप्रेटर	भाषा दी गई हो, तो भाषा में वाक्यों को समझने के लिए प्रतिनिधि का उपयोग करते हुए, दुभाषिए के ज़रिए प्रतिनिधित्व को व्याकरण समेत परिभाषित करता है.	हाँ	नहीं	नहीं	नहीं
इटरेटर	एक समग्र ऑब्जेक्ट के तत्वों के उपयोग के लिए, उसके अंतर्निहित प्रतिनिधित्व को बिना प्रकाश में लाते हुए, क्रमानुसार अभिगम प्रदान करता है.	हाँ	हाँ	नहीं	नहीं
मीडिएटर	एक ऑब्जेक्ट को परिभाषित करता है, जो आवेष्टित करता है कि ऑब्जेक्ट के एक सेट में कैसे परस्पर क्रिया होती है. मीडिएटर, ऑब्जेक्ट को एक दूसरे को स्पष्ट रूप से संदर्भित करते हुए लूज़ कपलिंग को बढ़ावा देता है, और उनकी अन्योन्य क्रिया को स्वतंत्र रूप से अलग करने की आपको अनुमति देता है.	हाँ	नहीं	नहीं	नहीं
रेस्टोरर	मौजूदा मेमेंटो पैटर्न के लिए एक विकल्प.	नहीं	नहीं	नहीं	नहीं
मेमेंटो	आवेष्टन का उल्लंघन किये बिना, एक ऑब्जेक्ट की आंतरिक स्थिति को कैप्चर और बाहर करता है, ताकि ऑब्जेक्ट को बाद में इस स्थिति में लौटाया जा सके.	हाँ	नहीं	नहीं	नहीं
नल ऑब्जेक्ट	एक ऑब्जेक्ट के डिफ़ॉल्ट मान के रूप में कार्य करने के लिए डिजाइन किया गया.	नहीं	नहीं	नहीं	नहीं
ऑब्सर्वर या पब्लिश/सबस्क्राइब{/0	ऑब्जेक्ट के बीच, वन-टु-मेनी डिपेंडेंसी को परिभाषित करता है, ताकि जब एक ऑब्जेक्ट परिवर्तित होता है तो इसके सभी आश्रित अधिसूचित और स्वतः नवीनीकृत हो जाएं.	हाँ	हाँ	नहीं	नहीं
ब्लैकबोर्ड	सामान्यीकृत ऑब्सर्वर, जो कई पाठकों और लेखकों को अनुमति देता है. सूचना को पूरे प्रणाली में भेजता है.	नहीं	नहीं	नहीं	नहीं
स्टेट	एक ऑब्जेक्ट को उसके व्यवहार में परिवर्तन की अनुमति देता है, जब उसकी आंतरिक स्थिति बदलती है. ऑब्जेक्ट अपने वर्ग परिवर्तन के लिए दिखाई देगा.	हाँ	नहीं	नहीं	नहीं
स्ट्रेटजी	एल्गोरिदम के परिवार को परिभाषित करता है, प्रत्येक को आवेष्टित करता है, और उन्हें परस्पर बदलने योग्य बनाता है. रणनीति, एल्गोरिथ्म को प्रयोग करने वाले क्लाइंट से स्वतंत्र रूप से अलग होने की अनुमति देता है.	हाँ	हाँ	नहीं	नहीं
स्पेसीफिकेशन	एक बूलीयन फैशन में पुनर्संयोजनीय व्यापार तर्क	नहीं	नहीं	नहीं	नहीं
टेम्पलेट विधि	एक संक्रिया में उपवर्गों के लिए कुछ परिवर्तित चरणों के साथ, एल्गोरिथ्म के ढाँचे को परिभाषित करता है. टेम्पलेट विधि, उपवर्गों को एल्गोरिथ्म की संरचना को बिना बदले, एल्गोरिथ्म के कुछ ख़ास चरणों को दुबारा परिभाषित करने की अनुमति देती है.	हाँ	हाँ	नहीं	नहीं
विज़िटर	ऑब्जेक्ट संरचना के तत्वों पर की जाने वाली एक संक्रिया को दर्शाता है. विज़िटर, जिन तत्वों के वर्ग पर परिचालित होता है, उन्हें बिना बदले, आपको एक नई संक्रिया को परिभाषित करने की अनुमति देता है.	हाँ	नहीं	नहीं	नहीं
कन्करेंसी पैटर्न
एक्टिव ऑब्जेक्ट	एक्टिव ऑब्जेक्ट डिज़ाइन पैटर्न, मेथड एक्ज़ीक्युशन को अपने ही थ्रेड ऑफ़ कंट्रोल में रहने वाले मेथड इन्वोकेशन से विसंबंधित करता है. इसका लक्ष्य होता है अतुल्यकालिक पद्धति से आह्वान करते हुए और अनुरोधों को संभालने के लिए शेड्यूलर के उपयोग द्वारा सम्मिलन प्रवर्तित करना.	नहीं	नहीं	हाँ	नहीं
बाइंडिंग प्रॉपर्टीज़	कई ऑब्सर्वरों को, किसी रूप में समक्रमित या समन्वित किए जाने वाले विभिन्न ऑब्जेक्ट में प्रोपर्टीज़ डालने के लिए मिलाया जाता है.	नहीं	नहीं	नहीं	नहीं
इवेंट-आधारित एसिन्क्रोन	इवेंट-आधारित अतुल्यकालिक डिज़ाइन पैटर्न, मल्टीथ्रेड प्रोग्राम में होने वाले अतुल्यकालिक पैटर्न की समस्याओं को हल करते हैं.	नहीं	नहीं	नहीं	नहीं
बाल्किंग	बाल्किंग पैटर्न, एक सॉफ्टवेयर डिज़ाइन पैटर्न है, जो किसी ऑब्जेक्ट पर केवल उस वक्त कार्य निष्पादित करता है, जब वह ऑब्जेक्ट एक विशेष स्थिति में हो.	नहीं	नहीं	नहीं	नहीं
गार्डेड सस्पेंशन	कन्करेंट प्रोग्रामिंग में, गार्डेड सस्पेंशन, उन संक्रियाओं के प्रबंधन के लिए एक सॉफ्टवेयर डिज़ाइन पैटर्न है, जिन्हें एक लॉक प्राप्त करने की और संक्रिया के निष्पादन से पहले संतुष्ट होने के लिए एक पूर्व शर्त की जरूरत होती है.	नहीं	नहीं	नहीं	नहीं
मॉनिटर ऑब्जेक्ट	मोनिटर एक अभिगम है, जो दो या दो से अधिक कम्प्यूटर कार्यों को समक्रमिक बनाने के लिए प्रयुक्त होता है, जो एक साझा रिसोर्स, आम तौर पर एक हार्डवेयर उपकरण या वेरिएबल्स के एक सेट का उपयोग करते हैं.	नहीं	नहीं	हाँ	नहीं
शेड्यूलर	शेड्यूलर पैटर्न एक संगामी पैटर्न है जिसका प्रयोग, नियंत्रण के लिए स्पष्ट रूप से तब किया जाता है, जब थ्रेड द्वारा एकल-थ्रेड कोड क्रियान्वयन की संभावना हो.	नहीं	नहीं	नहीं	नहीं
थ्रेड पूल	प्रोग्रामिंग के थ्रेड पूल पैटर्न में, कई थ्रेड कई कार्य संपादित करने के लिए निर्मित किये जाते हैं, जिन्हें आम तौर पर एक कतार में आयोजित किया जाता है. विशिष्ट रूप से, थ्रेड से कहीं ज्यादा, कार्य होते हैं.	नहीं	नहीं	नहीं	नहीं
थ्रेड-स्पेसिफिक स्टोरेज	थ्रेड-लोकल स्टोरेज (TLS) एक कंप्यूटर प्रोग्रामिंग का तरीका है, जो एक थ्रेड पर स्टैटिक या ग्लोबल मेमोरी लोकल का प्रयोग करता है.	नहीं	नहीं	हाँ	नहीं
रिएक्टर	रिएक्टर डिज़ाइन पैटर्न एक संगामी प्रोग्रामिंग पैटर्न है, जिसका प्रयोग एक या एक से अधिक इनपुट द्वारा सर्विस अनुरोधों को समानान्तर रूप से एक सर्विस हैंडलर तक पहुंचाने के लिए होता है. इसके बाद सर्विस हैंडलर, आने वाले अनुरोधों को डीमल्टीप्लेक्स करता है और उन्हें तुल्यकालिक तरीके से संबंधित अनुरोध संचालकों को भेजता है.	नहीं	नहीं	हाँ	नहीं
लॉक	एक थ्रेड, अन्य थ्रेड को इसके उपयोग करने या इसे संशोधित करने से रोकते हुए, एक संसाधन पर एक "लॉक" लगाता है.	नहीं	नहीं	नहीं	हाँ
डबल चेक्ड लॉकिंग	डबल चेक्ड लॉकिंग, एक सॉफ्टवेयर डिज़ाइन पैटर्न है जिसे "डबल चेक्ड लॉकिंग ऑप्टिमाईज़ेशन" के नाम से भी जाना जाता है. इस पैटर्न को, सर्वप्रथम एक असुरक्षित तरीके से लॉकिंग मानक ('लॉक हिंट') की जांच द्वारा एक लॉक प्राप्त करने के उपरिव्यय को कम करने के लिए डिज़ाइन किया गया है; यदि यह सफल होता है, तब ही वास्तविक लॉक आगे बढ़ता है.यह पैटर्न, जब किसी भाषा/हार्डवेयर संयोजन में कार्यान्वित होता है, तो असुरक्षित हो सकता है. इसलिए इसे कभी-कभी एंटी-पैटर्न भी माना जा सकता है.	नहीं	नहीं	हाँ	नहीं
रीड राईट लॉक	किसी ऑब्जेक्ट को समवर्ती पठन की अनुमति देता है, लेकिन लिखने की संक्रियाओं के लिए अनन्य अभिगम की आवश्यकता होती है.	नहीं	नहीं	नहीं	नहीं

प्रलेखन

एक डिज़ाइन पैटर्न के लिए प्रलेखन, उस संदर्भ, जिसमें इस पैटर्न का उपयोग किया गया है, संदर्भ के अंदर के फ़ोर्स जिसे पैटर्न सुलझाने का प्रयास करता है, और प्रस्तावित समाधान की व्याख्या करता है. डिज़ाइन पैटर्न को प्रलेखित करने के लिए कोई एक मानक प्रारूप नहीं है. बल्कि, विभिन्न पैटर्न लेखकों द्वारा विभिन्न प्रकार के प्रारूपों का प्रयोग किया गया है. तथापि, मार्टिन फोलर के अनुसार, कुछ निश्चित पैटर्न प्रारूप अन्य प्रारूपों की तुलना में ज्यादा लोकप्रिय हो गए हैं, और फलस्वरूप पैटर्न लेखन के नए प्रयासों के लिए एक आम आरंभिक चरण बन गए हैं. आम तौर पर इस्तेमाल किये जाने वाले प्रलेखन प्रारूप का एक उदाहरण है, एरिक गामा, रिचर्ड हेम, राल्फ जॉनसन और जॉन लिसिडेस (जो सामूहिक रूप से "द गैंग ऑफ़ फोर" या संक्षेप में Gof के तौर पर जाने जाते हैं) द्वारा उनकी पुस्तक डिज़ाइन पैटर्न में प्रयुक्त प्रारूप. इसमें निम्नलिखित वर्ग हैं:

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

आलोचना

कंप्यूटर विज्ञान के क्षेत्र में, डिज़ाइन पैटर्न की अवधारणा के बारे में कुछ आलोचनाएं मौजूद हैं.

ओवर-इंजीनियरिंग

डिज़ाइन पैटर्न का दुरुपयोग, अनावश्यक कोड को लागू करने में परिणत हो सकता है. यह कुशल सॉफ्टवेयर विकास की सादगी के प्रतिमान के विपरीत है.

लापता भाषा गुणों के लिए वर्कअराउंड

डाइनमिक प्रोग्रामिंग लैंग्वेज के उपयोगकर्ताओं ने कई डिज़ाइन पैटर्न की भाषाओं, जैसे C++ और Java की सीमाओं के लिए वर्कअराउंड के रूप में चर्चा की है. उदाहरण के लिए, विज़िटर पैटर्न को उस भाषा में लागू करने की जरूरत नहीं है, जो मुल्टीमेथड्स का समर्थन करती है. विज़िटर का उद्देश्य मौजूदा वर्गों में, उन्हें बिना संशोधित किए नई संक्रियाएं जोड़ना है. C++ में, एक वर्ग को एक विशिष्ट और बंद तरीकों के सेट वाले, सिंटैक्टिक स्ट्रक्चर के रूप में घोषित किया गया है. मुल्टीमेथड्स वाली एक भाषा में, जैसे कॉमन लिस्प वर्ग के लिए तरीके, उस वर्ग संरचना से बाहर होते हैं, और व्यक्ति उन्हें बिना बदले नए तरीके जोड़ सकता है. इसी तरह, डेकोरेटर पैटर्न, डाइनेमिक डेलीगेशन के कार्यान्वयन के बराबर है, जैसा कि कॉमन लिस्प, ऑब्जेक्टिव C, सेल्फ और JavaScript में पाया जाता है.

पीटर नोर्विग ने डिज़ाइन पैटर्न इन डाइनमिक प्रोग्रामिंग में डाइनमिक भाषाओं में विभिन्न पैटर्न को कार्यान्वित करने की घिसी-पिटी बात की चर्चा करते हैं. नोर्विग और अन्य ने उन भाषा गुणों की व्याख्या की है, जो विभिन्न पैटर्न को आवेष्टित या स्थानापन्न करते हैं, जिसे C++ के उपयोगकर्ता को स्वयं के लिए लागू करना जरूरी होगा.

अन्य पृथक्करणों से अधिक भिन्न नहीं है

कुछ लेखकों का आरोप है कि डिज़ाइन पैटर्न, एब्स्ट्रेक्शन^{[कृपया उद्धरण जोड़ें]} के अन्य रूपों से महत्वपूर्ण रूप से भिन्न नहीं हैं, और प्रोग्रामिंग के क्षेत्र में मौजूदा तथ्यविषयक वर्णन के लिए नई शब्दावली का प्रयोग (आर्कीटेक्चर समुदाय से लिया गया) अनावश्यक है. मॉडल-व्यू-कनट्रोलर प्रतिमान को "पैटर्न" के एक उदाहरण के रूप में उद्धृत किया गया है, जो "डिज़ाइन पैटर्न" की अवधारणा से कई वर्षों पहले से व्याप्त है. इस पर कुछ और लोग तर्क देते हैं कि डिज़ाइन पैटर्न समुदाय का प्राथमिक योगदान (और गैंग ऑफ़ फोर बुक) अलेक्जेंडर की पैटर्न भाषा का इस्तेमाल प्रलेखन के एक रूप में करना था; एक अभ्यास जिसे अक्सर साहित्य में नजरअंदाज किया गया है.^{[कृपया उद्धरण जोड़ें]}

यह भी देखें

• एब्स्ट्रेक्शन सिद्धांत (प्रोग्रामिंग)
• एंटी-पैटर्न
• आर्कीटेक्चरल पैटर्न
• बिज़नेस पैटर्न
• क्रिस्टोफर अलेक्जेंडर
• डिस्ट्रीब्यूटेड डिज़ाइन पैटर्न
• डबल-चांस फंक्शन
• GRASP (ऑब्जेक्ट-उन्मुख डिज़ाइन)
• इंटरएक्शन डिज़ाइन पैटर्न
• सॉफ्टवेयर विकास चिंतनों की सूची
• सॉफ्टवेयर इंजीनियरिंग विषयों की सूची
• पैटर्न भाषा
• पैटर्न सिद्धांत
• शैक्षणिक पैटर्न
• पोर्टलैंड पैटर्न भंडार
• रीफैकट्रिंग
• सॉफ्टवेयर विकास पद्धति

अतिरिक्त पठन

पुस्तकें

• Alexander, Christopher; Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King, Shlomo Angel (1977). A Pattern Language: Towns, Buildings, Construction. New York: Oxford University Press. आई॰ऍस॰बी॰ऍन॰ 978-0195019193. 
• Alur, Deepak; John Crupi, Dan Malks (May 2003). Core J2EE Patterns: Best Practices and Design Strategies (2nd Edition). Prentice Hall. आई॰ऍस॰बी॰ऍन॰ 0131422464. 
• Beck, Kent (October 2007). Implementation Patterns. Addison-Wesley. आई॰ऍस॰बी॰ऍन॰ 978-0321413093. 
• Beck, Kent; R. Crocker, G. Meszaros, J.O. Coplien, L. Dominick, F. Paulisch, and J. Vlissides (March 1996). Proceedings of the 18th International Conference on Software Engineering. pp. 25–30. 
• Borchers, Jan (2001). A Pattern Approach to Interaction Design. John Wiley & Sons. आई॰ऍस॰बी॰ऍन॰ 0-471-49828-9. 
• Coplien, James O.; Douglas C. Schmidt (1995). Pattern Languages of Program Design. Addison-Wesley. आई॰ऍस॰बी॰ऍन॰ 0-201-60734-4. 
• Coplien, James O.; John M. Vlissides, and Norman L. Kerth (1996). Pattern Languages of Program Design 2. Addison-Wesley. आई॰ऍस॰बी॰ऍन॰ 0-201-89527-7. 
• Fowler, Martin (1997). Analysis Patterns: Reusable Object Models. Addison-Wesley. आई॰ऍस॰बी॰ऍन॰ 0-201-89542-0. 
• Fowler, Martin (2002). Patterns of Enterprise Application Architecture. Addison-Wesley. आई॰ऍस॰बी॰ऍन॰ 978-0321127426. 
• Freeman, Eric; Elisabeth Freeman, Kathy Sierra, and Bert Bates (2004). Head First Design Patterns. O'Reilly Media. आई॰ऍस॰बी॰ऍन॰ 0-596-00712-4. 
• Alur, Deepak; Elisabeth Freeman, Kathy Sierra, and Bert Bates (2004). Head First Design Patterns. O'Reilly Media. आई॰ऍस॰बी॰ऍन॰ 0-596-00712-4. 
• Gabriel, Richard (1996) (PDF). Patterns of Software: Tales From The Software Community. Oxford University Press. pp. 235. आई॰ऍस॰बी॰ऍन॰ 0-19-512123-6. http://www.dreamsongs.com/NewFiles/PatternsOfSoftware.pdf. 
• Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. आई॰ऍस॰बी॰ऍन॰ 0-201-63361-2. 
• Hohpe, Gregor; Bobby Woolf (2003). Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley. आई॰ऍस॰बी॰ऍन॰ 0-321-20068-3. 
• Holub, Allen (2004). Holub on Patterns. Apress. आई॰ऍस॰बी॰ऍन॰ 1-59059-388-X. 
• Kerievsky, Joshua (2004). Refactoring to Patterns. Addison-Wesley. आई॰ऍस॰बी॰ऍन॰ 0-321-21335-1. 
• Kircher, Michael; Markus Völter and Uwe Zdun (2005). Remoting Patterns: Foundations of Enterprise, Internet and Realtime Distributed Object Middleware. John Wiley & Sons. आई॰ऍस॰बी॰ऍन॰ 0-470-85662-9. 
• Larman, Craig (2005). Applying UML and Patterns. Prentice Hall. आई॰ऍस॰बी॰ऍन॰ 0-13-148906-2. 
• Liskov, Barbara; John Guttag (2000). Program Development in Java: Abstraction, Specification, and Object-Oriented Design.. Addison-Wesley. आई॰ऍस॰बी॰ऍन॰ 0-201-65768-6. 
• Manolescu, Dragos; Markus Voelter and James Noble (2006). Pattern Languages of Program Design 5. Addison-Wesley. आई॰ऍस॰बी॰ऍन॰ 0-321-32194-4. 
• Marinescu, Floyd (2002). EJB Design Patterns: Advanced Patterns, Processes and Idioms. John Wiley & Sons. आई॰ऍस॰बी॰ऍन॰ 0-471-20831-0. 
• Martin, Robert Cecil; Dirk Riehle and Frank Buschmann (1997). Pattern Languages of Program Design 3. Addison-Wesley. आई॰ऍस॰बी॰ऍन॰ 0-201-31011-2. 
• Mattson, Timothy G; Beverly A. Sanders and Berna L. Massingill (2005). Patterns for Parallel Programming. Addison-Wesley. आई॰ऍस॰बी॰ऍन॰ 0-321-22811-1. 
• Shalloway, Alan; James R. Trott (2001). Design Patterns Explained, Second Edition: A New Perspective on Object-Oriented Design. Addison-Wesley. आई॰ऍस॰बी॰ऍन॰ 0-321-24714-0. 
• Vlissides, John M. (1998). Pattern Hatching: Design Patterns Applied. Addison-Wesley. आई॰ऍस॰बी॰ऍन॰ 0-201-43293-5. 
• Weir, Charles; James Noble (2000). Small Memory Software: Patterns for systems with limited memory. Addison-Wesley. आई॰ऍस॰बी॰ऍन॰ 0201596075. http://www.cix.co.uk/~smallmemory/. 

वेब साइटें

• "History of Patterns". Portland Pattern Repository. http://www.c2.com/cgi-bin/wiki?HistoryOfPatterns. अभिगमन तिथि: 2005-07-28. 
• "Are Design Patterns Missing Language Features?". Cunningham & Cunningham, Inc.. http://www.c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatures. अभिगमन तिथि: 2006-01-20. 
• "Show Trial of the Gang of Four". Cunningham & Cunningham, Inc.. http://www.c2.com/cgi/wiki?ShowTrialOfTheGangOfFour. अभिगमन तिथि: 2006-01-20. 

बाह्य लिंक

• Directory of websites that provide pattern catalogs hillside.net पर
• वार्ड कनिंघम की पोर्टलैंड पैटर्न रिपॉज़िटरी
• मुक्त निर्देशिका परियोजना पर Patterns and Anti-Patterns
• PerfectJPattern Open Source Project डिज़ाइन पैटर्न लाइब्ररी, जिसका लक्ष्य Java के सभी ज्ञात पैटर्न के पूर्ण या आंशिक संघटकीय संस्करण प्रदान करना है.
• Jt J2EE पैटर्न उन्मुख फ्रेमवर्क
• Printable Design Patterns Quick Reference Cards
• 101 Design Patterns & Tips for Developers
• On Patterns and Pattern Languages बुशमन, हेनी, और श्मिट द्वारा
• Patterns for Scripted Applications
• Oodesign.com पर Design Patterns Reference