डिझाइन नमुने

1.1 नमुन्यांची ओळख

आधी सांगितल्याप्रमाणे, प्रोग्रामर त्याचे मॉडेल डिझाइन करून प्रोग्रामवर काम सुरू करतो: प्रोग्राम ज्यावर कार्य करेल त्यांची यादी संकलित करणे. आणि प्रोग्राममध्ये जितके जास्त घटक असतील तितका प्रोग्राम अधिक जटिल.

म्हणून, प्रोग्रामची जटिलता कमी करण्यासाठी, ते ऑब्जेक्ट्सच्या परस्परसंवादांना प्रमाणित करण्याचा प्रयत्न करतात. आणि इथेच डिझाइन पॅटर्न किंवा डिझाइन पॅटर्न प्रोग्रामरला खूप मदत करतात . इंग्रजी डिझाइन पॅटर्नमधून .

महत्वाचे! रशियन भाषेत, डिझाइन शब्दाचा अर्थ सामान्यतः ग्राफिक डिझाइन असा होतो, इंग्रजीमध्ये असे नाही. इंग्रजी शब्द डिझाइन हा शब्द "डिझाइन" आणि / किंवा "डिव्हाइस" या शब्दाच्या जवळ आहे. उदाहरणार्थ, इंजिनची रचना हे त्याचे स्वरूप नसून त्याची अंतर्गत रचना असते.

म्हणून, डिझाईन पॅटर्न हा अगदी डिझाईन नमुना/नमुना असतो. मी शिफारस करतो की तुम्ही डिझाइन हा शब्द पूर्णपणे “स्वरूप” या अर्थाने वापरणे थांबवा. तुम्ही भविष्यातील सॉफ्टवेअर अभियंता आहात आणि तुमच्यासाठी डिझाईन अगदी अचूक आहे.

मग हे डिझाइन पॅटर्न काय आहे? सर्व प्रथम, डिझाइन पॅटर्न हे मानक समस्येचे मानक निराकरण आहे . एक चांगला, प्रभावी आणि वेळ-चाचणी उपाय.

समजा तुम्हाला सायकलची रचना करायला सांगितली होती, तुम्ही ती दोन चाके, तीन किंवा पाचही बनवू शकता. तर तसे, डिझाइनच्या पहाटे ते होते. पण वेळ-चाचणी दृष्टीकोन दोन चाके आहे. परंतु सध्याचा स्पष्ट दृष्टीकोन वेदना आणि चुकांमधून गेला:

सामान्यतः, टेम्पलेट हे एक संपूर्ण समाधान नाही जे थेट कोडमध्ये रूपांतरित केले जाऊ शकते, ते विविध परिस्थितींमध्ये वापरल्या जाणार्‍या समस्येच्या चांगल्या निराकरणाचे फक्त एक उदाहरण आहे.

ऑब्जेक्ट-ओरिएंटेड नमुने कोणते अंतिम वर्ग किंवा अनुप्रयोग ऑब्जेक्ट वापरले जातील हे निर्दिष्ट न करता वर्ग किंवा ऑब्जेक्ट्समधील संबंध आणि परस्परसंवाद दर्शवतात .

1.2 डिझाइन पॅटर्नचा इतिहास

70 च्या दशकात, प्रोग्रामरना मोठ्या प्रोग्राम विकसित करण्याची आवश्यकता होती ज्यावर संपूर्ण विकास कार्यसंघांनी काम केले होते. काम आयोजित करण्याच्या विविध पद्धती वापरल्या गेल्या, परंतु बांधकाम उद्योगाने विकासावर सर्वाधिक प्रभाव टाकला.

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

आणि जसे आपण अंदाज लावू शकता, डिझाइन पॅटर्नची कल्पना देखील बांधकाम उद्योगातून घेतली गेली होती. पॅटर्नची संकल्पना प्रथम ख्रिस्तोफर अलेक्झांडरने द पॅटर्न लँग्वेजमध्ये वर्णन केली होती. शहरे. इमारत. बांधकाम". या पुस्तकात शहराच्या रचनेच्या प्रक्रियेचे वर्णन करण्यासाठी खास भाषा, नमुने वापरण्यात आले आहेत.

बांधकामातील नमुने ठराविक वेळ-चाचणी निर्णयांचे वर्णन करतात: खिडक्या किती उंच असाव्यात, इमारतीत किती मजले असावेत, मायक्रोडिस्ट्रिक्टमध्ये झाडे आणि लॉनसाठी किती क्षेत्रफळ दिले जावे.

म्हणून, हे आश्चर्यकारक नाही की 1994 मध्ये "टेक्निक्स ऑफ ऑब्जेक्ट-ओरिएंटेड डिझाइन" हे पुस्तक. डिझाइन पॅटर्न”, ज्यामध्ये 23 पॅटर्न समाविष्ट आहेत जे ऑब्जेक्ट-ओरिएंटेड डिझाइनच्या विविध समस्यांचे निराकरण करतात.

हे पुस्तक चार लेखकांनी लिहिले होते: एरिक गामा, रिचर्ड हेल्म, राल्फ जॉन्सन आणि जॉन व्लिसाइड्स. पुस्तकाचे शीर्षक कोणाच्या लक्षात राहण्यासारखे लांब होते. म्हणून, लवकरच प्रत्येकजण याला “बुक बाय द गँग ऑफ फोर” म्हणू लागला, म्हणजेच “चार जणांच्या टोळीचे पुस्तक” आणि मग “GoF बुक” देखील.

आणि तेव्हापासून, इतर डिझाइन नमुने शोधले गेले आहेत. प्रोग्रामिंगच्या सर्व क्षेत्रांमध्ये "नमुना" दृष्टीकोन लोकप्रिय झाला आहे, म्हणून आता आपण ऑब्जेक्ट डिझाइनच्या बाहेर सर्व प्रकारचे नमुने शोधू शकता.

महत्वाचे! नमुने हे काही सुपर-ओरिजिनल सोल्यूशन्स नाहीत, परंतु, उलटपक्षी, वारंवार समोर येणारे, समान समस्येचे वैशिष्ट्यपूर्ण उपाय आहेत. चांगले सिद्ध उपाय.

1.3 नमुन्यांची सूची

अनेक प्रोग्रामर त्यांच्या संपूर्ण आयुष्यात एकही नमुना शिकलेले नाहीत, जे त्यांना वापरण्यापासून रोखत नाही. आम्ही आधी म्हटल्याप्रमाणे, नमुने हे चांगले वेळ-चाचणी उपाय आहेत आणि जर प्रोग्रामर मूर्ख नसेल तर तो स्वतः अनुभवाने असे उपाय शोधतो.

परंतु, डझनभर चाचण्या आणि त्रुटींमधून, इष्टतम उपायांकडे का यावे, जेव्हा असे लोक आहेत जे आधीच या मार्गावर गेले आहेत आणि त्यांच्या अनुभवाच्या आणि जीवनातील शहाणपणाने पुस्तके लिहिली आहेत?

आपण पाना सह एक नखे हातोडा शकता, पण का? आपण कठोर प्रयत्न केल्यास आपण ड्रिल देखील वापरू शकता. परंतु वाद्याचा चांगला जाणीवपूर्वक ताबा हाच व्यावसायिकाला हौशीपासून वेगळे करतो. आणि व्यावसायिकांना माहित आहे की ड्रिलचे मुख्य वैशिष्ट्य यात अजिबात नाही. तर, तुम्हाला नमुने का माहित असणे आवश्यक आहे?

• सिद्ध उपाय. चाक पुन्हा शोधण्याऐवजी तुम्ही ऑफ-द-शेल्फ सोल्यूशन्स वापरून कमी वेळ घालवता. काही निर्णय तुम्ही स्वतःबद्दल विचार करू शकता, परंतु बरेच काही तुमच्यासाठी शोध असू शकतात.
• कोड मानकीकरण. ठराविक युनिफाइड सोल्यूशन्स वापरून डिझाईन करताना तुम्ही कमी चुकीची गणना करता, कारण त्यातील सर्व लपलेल्या समस्या फार पूर्वीपासून सापडल्या आहेत.
• सामान्य प्रोग्रामिंग शब्दकोश. तुम्ही इतर प्रोग्रामरना कोणते छान डिझाइन आणले आहे आणि यासाठी कोणते वर्ग आवश्यक आहेत हे समजावून सांगण्यासाठी एक तास घालवण्याऐवजी तुम्ही पॅटर्नचे नाव सांगा.

नमुने काय आहेत?

डिझाईन केल्या जात असलेल्या प्रणालीची जटिलता, तपशील आणि कव्हरेजच्या पातळीमध्ये नमुने भिन्न आहेत. बांधकामाशी साधर्म्य रेखाटून, तुम्ही ट्रॅफिक लाइट लावून चौकाची सुरक्षितता वाढवू शकता किंवा तुम्ही छेदनबिंदूची जागा अंडरपाससह संपूर्ण कार इंटरचेंजने बदलू शकता.

सर्वात निम्न-स्तरीय आणि साधे नमुने मुहावरे आहेत. ते सार्वत्रिक नाहीत, कारण ते केवळ एका प्रोग्रामिंग भाषेच्या चौकटीत लागू होतात.

सर्वात अष्टपैलू आर्किटेक्चरल नमुने आहेत जे जवळजवळ कोणत्याही भाषेत लागू केले जाऊ शकतात. ते संपूर्ण प्रोग्राम डिझाइन करण्यासाठी आवश्यक आहेत, आणि त्याचे वैयक्तिक घटक नाही.

परंतु मुख्य गोष्ट अशी आहे की नमुने हेतूनुसार भिन्न आहेत. आपण ज्या नमुन्यांची ओळख करून घेऊ ते तीन मुख्य गटांमध्ये विभागले जाऊ शकतात:

• क्रिएशन पॅटर्न प्रोग्राममध्ये अनावश्यक अवलंबनांचा परिचय न करता ऑब्जेक्ट्सच्या लवचिक निर्मितीची काळजी घेतात.
• स्ट्रक्चरल नमुने वस्तूंमधील संबंध निर्माण करण्याचे वेगवेगळे मार्ग दाखवतात.
• वर्तणूक पद्धती वस्तूंमधील कार्यक्षम संवादाची काळजी घेतात.

1.4 UML चा परिचय

गँग ऑफ फोर पुस्तकात वर्णन केलेल्या त्याच 23 नमुन्यांची सुरुवात करूया. स्वतःचे नमुने आणि त्यांची नावे दोन्ही अगदी नवशिक्या प्रोग्रामरसाठी परिचित गोष्टी आहेत. मी तुम्हाला त्यांची ओळख करून देईन, परंतु मी नमुन्यांबद्दल तेच पुस्तक वाचण्याची जोरदार शिफारस करतो.

डिझाइन पॅटर्न विशिष्ट प्रोग्रामिंग भाषेशी जोडलेले नाहीत, म्हणून यूएमएल सहसा त्यांचे वर्णन करण्यासाठी वापरले जाते. 20 वर्षांपूर्वी हे खूप लोकप्रिय होते, परंतु आताही ते कधीकधी वापरले जाते. आणि तसे, नमुन्यांचे वर्णन फक्त ते ठिकाण आहे जेथे UML चा वापर मानक आहे.

UML सह, तुम्ही वेगवेगळ्या घटकांमधील संबंधांचे वर्णन करू शकता. आमच्या बाबतीत, या वस्तू आणि वर्ग आहेत.

वर्गांमधील संबंधांचे वर्णन चार प्रकारच्या बाणांनी केले आहे:

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

खरं तर, येथे सर्वकाही अगदी सोपे आहे. शेवटच्या बाणाचा अर्थ असा होतो की एका वर्गाला दुसऱ्या वर्गाकडून वारसा मिळाला आहे. आणि पहिला आणि दुसरा बाण म्हणजे एक ऑब्जेक्ट दुसऱ्या ऑब्जेक्टची लिंक साठवतो. आणि हे सर्व आहे.

जर लिंक डायमंड काळा असेल तर दुवा कमकुवत आहे: वस्तू एकमेकांशिवाय अस्तित्वात असू शकतात. जर हिरा पांढरा असेल, तर वस्तू मजबूतपणे संबंधित आहेत, जसे की वर्ग HttpRequestआणि त्याचा बाल वर्ग HttpRequest.Builder.

1.5 नमुन्यांची यादी

नमुन्यांचे प्रकार भिन्न रंग आणि अक्षरांद्वारे दर्शविले जातील:

बी- वर्तणूक (वर्तणूक);

सी- निर्मिती (सर्जनशील);

एस- स्ट्रक्चरल (स्ट्रक्चरल).

आणि शेवटी, 23 डिझाइन नमुन्यांची यादी: