मुझे आश्चर्य है कि समाधान में फिट हो सकने वाले संभावित डिजाइन पैटर्न को समझने के लिए एक अच्छी तरह से परिभाषित समस्या के चरणबद्ध विश्लेषण दृष्टिकोण के चरण में क्या कदम होना चाहिए।उपयुक्त डिजाइन पैटर्न के साथ मिलान करने के लिए किसी समस्या का विश्लेषण कैसे करें?
कोई मार्गदर्शन जो आप सुझा सकते हैं?
धन्यवाद
कोई भी डिज़ाइन पैटर्न भंडार आपको संकेत देगा कि "यह उपयोगी है ...", लेकिन आमतौर पर ऐसी कोई अनुक्रमणिका नहीं होती है जो आपको "क्रेडिट कार्ड नंबर" और "फ्लाईवेट ऑब्जेक्ट" । उपलब्ध निकटतम चीज आम तौर पर व्यवहार, निर्माण आदि के रूप में पैटर्न के ढीले समूह को होती है।
मेरी राय में यह सोचकर कोई समस्या नहीं है कि आपको कौन सा डिज़ाइन पैटर्न लागू करना चाहिए। यदि आप किसी पैटर्न से पर्याप्त रूप से परिचित हैं, तो आप तुरंत ध्यान देंगे कि यह लागू होता है और कैसे। यदि आप फिट नहीं देखते हैं, तो केवल सेवा में पैटर्न को दबाए रखने का प्रयास करें ताकि आप कह सकें "मैंने पैटर्न XX का उपयोग किया है, इसलिए डिज़ाइन अच्छा होना चाहिए!" एक खतरनाक गलती है।
ऐसे लोग भी हैं जो यह भी कहते हैं कि डिजाइन पैटर्न पहले स्थान पर एक झुकाव हैं, यह संकेत है कि आपकी भाषा पर्याप्त अभिव्यक्तिपूर्ण नहीं है। (यह उतना पागल नहीं है जितना लगता है; मान लीजिए कि WHILE loops या हैश टेबल एक बार प्रोग्रामिंग भाषाओं से अनुपस्थित थे, और उस युग के मास्टर प्रोग्रामर को बार-बार उन्हें फिर से लागू करना होगा; अब वे वाक्यविन्यास का हिस्सा हैं, और कोई भी उन्हें 'पैटर्न' कहने का सपना नहीं देख पाएगा।) मैं, मैं चरमपंथी नहीं हूं; मुझे लगता है कि जब आप इसका इस्तेमाल करते हैं तो एक अच्छी तरह से चयनित डिज़ाइन पैटर्न वास्तव में बहुत उपयोगी हो सकता है क्योंकि आप इस बात से आश्वस्त हैं कि यह एक अच्छा समाधान है, लेकिन इसके लिए आपको इसे पूरी तरह से समझने की आवश्यकता है, और मेरे अनुभव में, यह लगभग हमेशा इसे स्वयं अभ्यास करने की आवश्यकता होती है । पैटर्न का मूल्य अक्सर कुछ ऐसा करने के लिए एक पहचानने योग्य नाम देने में निहित होता है, ताकि आप इसे बेहतर याद कर सकें और अपने साथियों के साथ संवाद कर सकें।
डिजाइन पैटर्न समस्या को सुलझाने के कार्यों की एक व्यापक विविधता धरना करना है। तो अमूर्त में आपको विभिन्न प्रकार के काम करने का प्रतिनिधित्व करने का तरीका है, और उस काम के खिलाफ एक डिजाइन पैटर्न से मेल खाने का एक तरीका है। इसे सामान्य रूप से करना "एआई-हार्ड" है।
"काम किया जा रहा" का एक विशिष्ट प्रतिनिधित्व स्पष्ट रूप से कंप्यूटर स्रोत कोड है। अब डिजाइन पैटर्न मिलान समस्या कोड टुकड़ों के एक सेट के खिलाफ मेल खाने में से एक है जो ब्याज की समस्या को प्रदर्शित करती है, और "पैटर्न" (उदाहरण के लिए, समाधान) को उन चरणों के सेट के रूप में लागू करती है जो वांछित परिणाम प्राप्त करने के लिए स्रोत कोड को संशोधित करती हैं।
ऐसे उपकरण जो ऐसे पैटर्न और प्रभाव को व्यक्त कर सकते हैं स्वचालित स्रोत कोड परिवर्तन Program Transformation इंजन है। आप एक इंजन के साथ आम तौर पर क्या करते हैं, एक साथ डिजाइन पैटर्न का एक बड़ा सेट इकट्ठा करना है, उन्हें स्रोत-टू-सोर्स रीराइट नियमों के सेट के रूप में तुरंत चालू करना है, और उसके बाद रूपांतरण इंजन को कोड का एक हिस्सा सौंपना ताकि यह पैटर्न कर सके -चैच/प्रतिस्थापन कदम। सबसे कठिन काम, ज़ाहिर है, डिजाइन पैटर्न को रूपांतरण नियमों के रूप में कोडिंग कर रहा है, क्योंकि ज्यादातर डिज़ाइन पैटर्न गद्य में लिखे जाते हैं और सटीक विवरण के बारे में थोड़ा अस्पष्ट होते हैं। (कार्यक्रम परिवर्तन इंजन बनाने के लिए बहुत मुश्किल है, लेकिन वे तर्कसंगत रूप से पहले से ही किए गए हैं :)
कार्यक्रम परिवर्तन इंजन का उपयोग रेफैक्टरिंग (डिजाइन पैटर्न के एक प्रसिद्ध वर्ग), भाषा अनुवाद (बड़े पैमाने पर "डिजाइन पैटर्न को लागू करने के लिए किया गया है) एप्लिकेशन "), और कोड पुनर्गठन जैसे कि नई जरूरतों को पूरा करने के लिए एपीआई को दोबारा बदलना (एक विशिष्ट उदाहरण मैंने सी ++ कोड एपीआई को कॉरबा-शिकायत में परिवर्तित करना स्वचालित कर दिया है)।
+1 अच्छा स्पर्श। मुझे यह पसंद है कि आपने डिज़ाइन पैटर्न को कुछ ऐसे तरीके के रूप में कैसे संबोधित किया है जिसे आपको गहराई से समझने और लागू होने पर उपयोग करने की आवश्यकता है; और उन्हें कैसे जानना फायदेमंद है ताकि आप अपने साथियों के साथ अपने इरादों को संवाद कर सकें।'इस प्रकार आप अपने कोड को डिज़ाइन पैटर्न के एकीकरण में बदलते हैं' दृष्टिकोण के बजाय। मेरी इच्छा है कि अधिक लोग पूर्व दृष्टिकोण लेंगे क्योंकि जो लोग सीढ़ी पर भरोसा करते हैं वे डिजाइन पैटर्न की पूरी अवधारणा को खराब नाम देते हैं। –