डिजाइन पैटर्न्स

1.1 पैटर्न का परिचय

जैसा कि पहले उल्लेख किया गया है, एक प्रोग्रामर अपने मॉडल को डिजाइन करके एक कार्यक्रम पर काम करना शुरू करता है: उन संस्थाओं की सूची संकलित करता है जिन पर कार्यक्रम संचालित होगा। और कार्यक्रम में जितनी अधिक संस्थाएँ होंगी, कार्यक्रम उतना ही जटिल होगा।

इसलिए, कार्यक्रम की जटिलता को कम करने के लिए, वे वस्तुओं की बातचीत को मानकीकृत करने का प्रयास करते हैं। और यहीं पर डिज़ाइन पैटर्न या डिज़ाइन पैटर्न प्रोग्रामर की बहुत मदद करते हैं । अंग्रेजी डिजाइन पैटर्न से ।

महत्वपूर्ण! रूसी में, डिज़ाइन शब्द का अर्थ आमतौर पर ग्राफिक डिज़ाइन होता है, अंग्रेजी में ऐसा नहीं है। अंग्रेजी शब्द डिजाइन "डिजाइन" और / या "डिवाइस" शब्द के अर्थ के करीब है। उदाहरण के लिए, किसी इंजन का डिज़ाइन उसका स्वरूप नहीं है, बल्कि उसकी आंतरिक संरचना है।

इसलिए, एक डिज़ाइन पैटर्न बिल्कुल एक डिज़ाइन पैटर्न/पैटर्न है। मेरा सुझाव है कि आप "उपस्थिति" के अर्थ में डिज़ाइन शब्द का उपयोग पूरी तरह से बंद कर दें। आप भविष्य के सॉफ़्टवेयर इंजीनियर हैं, और आपके लिए डिज़ाइन बिल्कुल डिज़ाइन है।

तो यह डिज़ाइन पैटर्न क्या है? सबसे पहले, एक डिज़ाइन पैटर्न एक मानक समस्या का एक मानक समाधान है । एक अच्छा, प्रभावी और समय-परीक्षणित समाधान।

मान लीजिए कि आपको एक साइकिल डिजाइन करने के लिए कहा गया है, आप इसे दो पहिये, तीन या पांच भी बना सकते हैं। तो वैसे, डिजाइन के भोर में, यह था। लेकिन समय-परीक्षणित दृष्टिकोण दो पहिए हैं। लेकिन वर्तमान स्पष्ट दृष्टिकोण दर्द और गलतियों से गुजरा:

आमतौर पर, एक टेम्पलेट एक पूर्ण समाधान नहीं है जिसे सीधे कोड में परिवर्तित किया जा सकता है, यह किसी समस्या के अच्छे समाधान का एक उदाहरण है जिसका उपयोग विभिन्न स्थितियों में किया जा सकता है।

ऑब्जेक्ट-ओरिएंटेड पैटर्न कक्षाओं या वस्तुओं के बीच संबंध और बातचीत दिखाते हैं , यह निर्दिष्ट किए बिना कि कौन से अंतिम वर्ग या एप्लिकेशन ऑब्जेक्ट का उपयोग किया जाएगा।

1.2 डिजाइन पैटर्न का इतिहास

70 के दशक में, प्रोग्रामरों को बड़े कार्यक्रमों को विकसित करने की आवश्यकता का सामना करना पड़ा, जिन पर संपूर्ण विकास टीमों द्वारा काम किया जाना था। कार्य को व्यवस्थित करने के विभिन्न तरीकों की कोशिश की गई, लेकिन निर्माण उद्योग ने विकास को सबसे अधिक प्रभावित किया।

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

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

निर्माण में पैटर्न विशिष्ट समय-परीक्षणित निर्णयों का वर्णन करते हैं: कितनी ऊंची खिड़कियां होनी चाहिए, इमारत में कितनी मंजिलें होनी चाहिए, पेड़ों और लॉन के लिए माइक्रोडिस्ट्रिक्ट में कितना क्षेत्र आवंटित किया जाना चाहिए।

इसलिए, यह आश्चर्य की बात नहीं है कि 1994 में "ऑब्जेक्ट-ओरिएंटेड डिज़ाइन की तकनीक" पुस्तक। डिज़ाइन पैटर्न", जिसमें 23 पैटर्न शामिल हैं जो ऑब्जेक्ट-ओरिएंटेड डिज़ाइन की विभिन्न समस्याओं को हल करते हैं।

पुस्तक 4 लेखकों द्वारा लिखी गई थी: एरिच गामा, रिचर्ड हेल्म, राल्फ जॉनसन और जॉन व्लिससाइड्स। पुस्तक का शीर्षक किसी के लिए भी याद रखने के लिए बहुत लंबा था। इसलिए, जल्द ही हर कोई इसे "चार के गिरोह की किताब", यानी "चार के गिरोह की एक किताब" और फिर "गोफ बुक" भी कहने लगा।

और तब से, अन्य डिज़ाइन पैटर्न खोजे गए हैं। प्रोग्रामिंग के सभी क्षेत्रों में "पैटर्न" दृष्टिकोण लोकप्रिय हो गया है, इसलिए अब आप ऑब्जेक्ट डिज़ाइन के बाहर सभी प्रकार के पैटर्न पा सकते हैं।

महत्वपूर्ण! पैटर्न कुछ सुपर-मूल समाधान नहीं हैं, बल्कि, इसके विपरीत, एक ही समस्या के लिए अक्सर सामना किए जाने वाले विशिष्ट समाधान हैं। अच्छा सिद्ध उपाय।

1.3 पैटर्न की सूची

कई प्रोग्रामरों ने अपने पूरे जीवन में एक भी पैटर्न नहीं सीखा है, जो उन्हें उनका उपयोग करने से नहीं रोकता है। जैसा कि हमने पहले कहा, पैटर्न अच्छे समय-परीक्षणित समाधान हैं, और यदि प्रोग्रामर मूर्ख नहीं है, तो अनुभव के साथ वह स्वयं ऐसे समाधान ढूंढता है।

लेकिन दर्जनों परीक्षणों और त्रुटियों के माध्यम से, इष्टतम समाधान क्यों आते हैं जब ऐसे लोग हैं जो पहले से ही इस तरह से जा चुके हैं और अपने अनुभव और जीवन ज्ञान की सर्वोत्कृष्टता के साथ किताबें लिख चुके हैं?

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

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

पैटर्न क्या हैं?

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

सबसे निम्न स्तर और सरल पैटर्न मुहावरे हैं। वे सार्वभौमिक नहीं हैं, क्योंकि वे केवल एक प्रोग्रामिंग भाषा के ढांचे के भीतर ही लागू होते हैं।

सबसे बहुमुखी वास्तुशिल्प पैटर्न हैं जिन्हें लगभग किसी भी भाषा में लागू किया जा सकता है। उन्हें पूरे कार्यक्रम को डिजाइन करने की जरूरत है, न कि इसके अलग-अलग तत्वों की।

लेकिन मुख्य बात यह है कि पैटर्न उद्देश्य में भिन्न होते हैं। जिन पैटर्नों से हम परिचित होंगे उन्हें तीन मुख्य समूहों में विभाजित किया जा सकता है:

• निर्माण पैटर्न कार्यक्रम में अनावश्यक निर्भरताओं को पेश किए बिना वस्तुओं के लचीले निर्माण का ख्याल रखता है।
• संरचनात्मक पैटर्न वस्तुओं के बीच संबंध बनाने के विभिन्न तरीके दिखाते हैं।
• व्यवहार पैटर्न वस्तुओं के बीच कुशल संचार का ख्याल रखते हैं।

1.4 यूएमएल का परिचय

आइए उन्हीं 23 प्रतिमानों को देखकर आरंभ करें जिनका वर्णन गैंग ऑफ फोर पुस्तक में किया गया था। नौसिखिए प्रोग्रामर के लिए भी दोनों पैटर्न और उनके नाम परिचित चीजें हैं। मैं आपको उनसे मिलवाऊंगा, लेकिन मैं पैटर्न के बारे में उसी किताब को पढ़ने की जोरदार सलाह देता हूं।

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

यूएमएल के साथ, आप विभिन्न संस्थाओं के बीच संबंधों का वर्णन कर सकते हैं। हमारे मामले में, ये वस्तुएं और वर्ग हैं।

वर्गों के बीच संबंधों को चार प्रकार के तीरों द्वारा वर्णित किया गया है:

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

वास्तव में, यहाँ सब कुछ बहुत सरल है। अंतिम तीर का वास्तव में मतलब है कि एक वर्ग दूसरे वर्ग से विरासत में मिला है। और पहला और दूसरा तीर यह है कि एक वस्तु दूसरी वस्तु के लिए एक कड़ी को संग्रहीत करती है। और यह सब है।

यदि लिंक हीरा काला है, तो लिंक कमजोर है: वस्तुएं एक दूसरे के बिना मौजूद हो सकती हैं। यदि हीरा सफेद है, तो वस्तुएँ दृढ़ता से संबंधित हैं, जैसे कि एक वर्ग HttpRequestऔर उसका उप वर्ग HttpRequest.Builder।

1.5 पैटर्न की सूची

पैटर्न के प्रकार विभिन्न रंगों और अक्षरों द्वारा निरूपित किए जाएंगे:

बी- व्यवहार (व्यवहार);

सी- उत्पन्न करना (रचनात्मक);

एस- संरचनात्मक (संरचनात्मक)।

और अंत में, 23 डिज़ाइन पैटर्न की एक सूची: