क्या हमें लगातार बदलती परियोजनाओं में डिजाइन पैटर्न का उपयोग करने से बचना चाहिए?

Question

मेरा एक दोस्त एक छोटी कंपनी के लिए एक प्रोजेक्ट पर काम कर रहा है, जिसे हर डेवलपर नफरत करता है: वह जितनी जल्दी हो सके जारी करने के लिए दबाव डाला जाता है, वह केवल एक है जो तकनीकी ऋण की परवाह करता है, ग्राहक के पास कोई तकनीकी पृष्ठभूमि नहीं है, आदि।

उन्होंने मुझे एक कहानी सुनाई जिसने मुझे इस तरह की परियोजनाओं में डिजाइन पैटर्न की उपयुक्तता के बारे में सोचा। यहाँ कहानी है।

हमें वेबसाइट पर विभिन्न स्थानों पर उत्पादों को प्रदर्शित करना था। उदाहरण के लिए, सामग्री प्रबंधक उत्पादों को देख सकते हैं, लेकिन अंतिम उपयोगकर्ताओं या भागीदारों को एपीआई के माध्यम से भी।

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

डिज़ाइन पैटर्न के बारे में मेरे हाल के रीडिंग से प्रेरित, मैंने सोचा कि यह जादुई नल ऑब्जेक्ट पैटर्न का उपयोग करने का एक शानदार अवसर था । तो मैंने इसे किया, और सब कुछ चिकनी और साफ था। एक को केवल product.Price.ToString("c")मूल्य प्रदर्शित करने के लिए कॉल करना था , या product.Description.Currentविवरण दिखाना था; कोई सशर्त सामान की आवश्यकता नहीं है। एक दिन पहले तक, हितधारक ने nullJSON में होने पर, एपीआई में इसे अलग तरीके से प्रदर्शित करने के लिए कहा । और "मूल्य अनिर्दिष्ट [बदलें]" दिखाकर सामग्री प्रबंधकों के लिए भी अलग तरह से। और मुझे अपने प्रिय नल ऑब्जेक्ट पैटर्न को मारना पड़ा, क्योंकि अब इसकी कोई आवश्यकता नहीं थी।

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

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

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

इस मामले में क्या समाधान होगा?

• किसी भी डिज़ाइन पैटर्न का उपयोग नहीं करना, सोचना बंद करना और सीधे कोड लिखना?

  एक अनुभव करना दिलचस्प होगा जहां एक टीम सीधे कोड लिख रही है, जबकि दूसरा व्यक्ति टाइप करने से पहले दो बार सोच रहा है, कुछ दिन बाद मूल डिजाइन को फेंकने का जोखिम उठा रहा है: कौन जानता है, शायद दोनों टीमों के पास होगा वही तकनीकी ऋण। इस तरह के डेटा के अभाव में, मैं केवल इस बात पर जोर दूंगा कि 20 महीने के प्रोजेक्ट पर काम करते समय बिना पूर्व विचार के कोड लिखना सही नहीं लगता ।

• उस डिज़ाइन पैटर्न को रखें जो अब किसी भी मायने नहीं रखता है, और नव निर्मित स्थिति के लिए और अधिक पैटर्न जोड़ने की कोशिश करता है?

  यह न तो सही प्रतीत होता है। कोड की समझ को सरल बनाने के लिए पैटर्न का उपयोग किया जाता है; बहुत अधिक पैटर्न डालें, और कोड गड़बड़ हो जाएगा।

• एक नई डिजाइन के बारे में सोचना शुरू करें जो नई आवश्यकताओं को शामिल करती है, फिर धीरे-धीरे पुराने डिजाइन को नए में फिर से शामिल करें?

  एक सिद्धांतकार और जो चपलता का पक्षधर है, मैं पूरी तरह से इसमें हूँ। व्यवहार में, जब आप जानते हैं कि आपको हर हफ्ते व्हाइटबोर्ड पर वापस जाना होगा और पिछले डिज़ाइन के बड़े हिस्से को फिर से बनाना होगा और ग्राहक के पास आपके लिए पर्याप्त धनराशि नहीं होगी, और न ही इंतजार करने के लिए पर्याप्त समय। , यह शायद काम नहीं करेगा।

तो, कोई सुझाव?

Comments

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

— रॉबर्ट हार्वे

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

— रॉबर्ट हार्वे

मुझे संदेह है कि डिज़ाइन पैटर्न के बिना, कोड बहुत जल्दी पहुंच से बाहर हो जाएगा

— स्टीवन ए। लोव

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

— जेसन सी

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

— जेसन सी

Answer 1

मैं इस प्रश्न में कुछ गलत धारणाएँ देखता हूँ:

• डिजाइन पैटर्न के साथ कोड, हालांकि सही ढंग से लागू किया जाता है, उन पैटर्न के बिना कोड की तुलना में लागू करने के लिए अधिक समय की आवश्यकता होती है।

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

• ग्राहक को दोष देना है क्योंकि उसके पास कोई तकनीकी पृष्ठभूमि नहीं है और उत्पाद के सामंजस्य या सुसंगतता की परवाह नहीं करता है

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

• तेजी से बदलती आवश्यकताओं का समाधान कोड को तेजी से बदलना है

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

Comments

+1 - आप तकनीकी समाधान के साथ लोगों की समस्याओं को हल नहीं कर सकते।

— तेलस्टीन जूल

+1, लेकिन "या कम से कम बेहतर साध्य (इसका मतलब है: बदलती आवश्यकताओं के लिए अनुकूलित किया जाना आसान)" - मैं इसे यथोचित रूप से बदलती आवश्यकताओं के साथ अर्हता प्राप्त करूंगा ?

— फ्यूहरमैनटर

@Fuhrmanator: मुझे लगता है कि सामान्य शब्दों में चर्चा करना कठिन है। IMHO यह स्पष्ट है कि कोई भी डिज़ाइन पैटर्न आपकी मदद नहीं करेगा जब आपकी पहली आवश्यकता "हमें एक वर्ड प्रोसेसर की आवश्यकता होती है" और यह "हमें उड़ान सिम्युलेटर की आवश्यकता है" में बदल जाता है। कम कठोर आवश्यकता परिवर्तनों के लिए यह तय करना हमेशा आसान नहीं होता है कि आपको अपने सॉफ्टवेयर को विकसित करने में क्या मदद मिलेगी। सबसे अच्छी बात यह है कि IMHO बहुत सारे पैटर्न लागू नहीं करता है, लेकिन कुछ सिद्धांत - मुख्य रूप से ठोस सिद्धांत और YAGNI। और मैं Telastyn के साथ 100% सहमत हूं- जब आवश्यकताएं बहुत बार बदलती हैं, तो यह संभवतः एक तकनीकी समस्या नहीं है।

— डॉक ब्राउन

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

— क्रिलगर

@ कॉर्नेलियस डॉक ब्राउन ने कहा कि यह बिना सुरीले के कठिन है। शब्द प्रोसेसर से उड़ान सिम्युलेटर में जाने की आवश्यकताएं उचित नहीं होंगी; कोई डिज़ाइन पैटर्न मदद नहीं करेगा। उनके उदाहरण के बीच में ग्रे क्षेत्र का एक बहुत कुछ है और, एक वर्ड प्रोसेसर के सेव फंक्शन (जो बहुत ही उचित है) में एक नया फाइल फॉर्मेट जोड़ते हैं। विशिष्टताओं के बिना, चर्चा करना कठिन है। इसके अलावा, ऐसा नहीं है कि कोई बदलना नहीं चाहेगा । यह है कि इस तरह के बदलाव मुश्किल हैं, अगर आपने पहले से ही आवश्यकता के आधार पर एक डिजाइन विकल्प बनाया है। प्रोसेसर बनाम फ्लाइट सिम शब्द प्रारंभिक पसंद का एक शानदार उदाहरण है।

— फ्यूहरमैनटर

Answer 2

मेरी विनम्र राय है कि आपको डिज़ाइन पैटर्न का उपयोग करने से बचना चाहिए या नहीं बचना चाहिए।

डिज़ाइन पैटर्न सामान्य समस्याओं के लिए केवल अच्छी तरह से ज्ञात और विश्वसनीय समाधान हैं, जिन्हें नाम दिया गया था। वे किसी भी अन्य समाधान या डिज़ाइन के बारे में तकनीकी रूप से भिन्न नहीं होते हैं जिनके बारे में आप सोच सकते हैं।

मुझे लगता है कि समस्या की जड़ यह हो सकती है कि आपका मित्र "डिजाइन पैटर्न लागू करने या न लागू करने" के संदर्भ में सोचता है, इसके बजाय "जो सबसे अच्छा समाधान है, मैं उसके बारे में सोच सकता हूं, लेकिन पैटर्न तक सीमित नहीं है। मुझे पता है"।

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

Comments

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

— जेसन सी

Answer 3

नल ऑब्जेक्ट पैटर्न का उपयोग करने के आपके उदाहरण में, मेरा मानना ​​है कि यह अंततः विफल हो गया क्योंकि यह प्रोग्रामर की जरूरतों को पूरा करता था और ग्राहक की जरूरतों को पूरा नहीं करता था। ग्राहक को संदर्भ के लिए उपयुक्त रूप में मूल्य प्रदर्शित करने की आवश्यकता है। प्रोग्रामर को कुछ प्रदर्शन कोड को सरल बनाने की आवश्यकता थी।

इसलिए, जब एक डिज़ाइन पैटर्न आवश्यकताओं को पूरा नहीं करता है, तो क्या हम कहते हैं कि सभी डिज़ाइन पैटर्न समय की बर्बादी हैं या क्या हम कहते हैं कि हमें एक अलग डिज़ाइन पैटर्न की आवश्यकता है?

Answer 4

ऐसा प्रतीत होता है कि पैटर्न वस्तुओं को हटाने के लिए गलती अधिक थी, उनका उपयोग करने की तुलना में। प्रारंभिक डिजाइन में, नल ऑब्जेक्ट एक समस्या का समाधान प्रदान करता है। यह सबसे अच्छा समाधान नहीं हो सकता है।

किसी प्रोजेक्ट पर काम करने वाले एकमात्र व्यक्ति होने के नाते आपको संपूर्ण विकास प्रक्रिया का अनुभव करने का मौका मिलता है। बड़ा नुकसान यह नहीं है कि कोई आपका गुरु हो। सबसे अच्छा या बेहतर अभ्यास सीखने और लागू करने के लिए समय लेने से भुगतान जल्दी होने की संभावना है। चाल पहचान रही है कि कौन सा अभ्यास कब सीखना है।

उत्पाद के रूप में चाइनिंग संदर्भ। Pice.toString ('c') Demeter कानून का उल्लंघन करता है । मैंने इस अभ्यास के साथ सभी प्रकार के मुद्दों को देखा है, जिनमें से कई नल से संबंधित हैं। Product.displayPrice ('c') जैसी विधि आंतरिक रूप से अशक्त कीमतों को संभाल सकती है। इसी तरह product.Description.Current को product.displayDescription (), product.displayCurrentDescription () द्वारा हैंडल किया जा सकता है। या product.diplay ('वर्तमान')।

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

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

Comments

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

— कॉर्नेलियस

Answer 5

इतने सारे बिंदुओं पर सवाल गलत लगता है। लेकिन मूत्राशय वाले हैं:

• आपके द्वारा बताए गए नल ऑब्जेक्ट पैटर्न के लिए, आवश्यकताओं में बदलाव के बाद, आप कोड को थोड़ा बदलते हैं। यह ठीक है, लेकिन इसका मतलब यह नहीं है कि आप अशक्त ऑब्जेक्ट पैटर्न 'हत्या' (btw, अपने शब्दों के साथ सावधान रहना होगा, यह बहुत चरम लगता है, कुछ लोगों को भी पागल यह सब के रूप में अजीब नहीं दिखेगा)।

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

• आपने जिस डिजाइन के बारे में बात की है, वह खराब है क्योंकि जब आवश्यकता में बदलाव मामूली चीजों के रूप में आता है, तो आप सभी जगहों पर बड़े पैमाने पर रणनीतिक डिजाइन में बदलाव करते हैं। जब तक उच्च-स्तरीय व्यावसायिक समस्या नहीं बदलती, आप बड़े पैमाने पर डिज़ाइन परिवर्तन को उचित नहीं ठहरा सकते।

मेरे अनुभव से, जब मामूली आवश्यकताएं आती हैं, तो आपको केवल कोडबेस के छोटे हिस्से को बदलने की आवश्यकता होती है। हो सकता है कि कुछ थोड़ा हैकी हो, लेकिन रख-रखाव या पठनीयता को काफी हद तक प्रभावित करने के लिए कुछ भी गंभीर नहीं है और हैकी भाग को समझाने के लिए टिप्पणी की कुछ पंक्तियाँ पर्याप्त होंगी। यह एक बहुत ही सामान्य अभ्यास है।

Answer 6

आइए एक पल के लिए रुकें और यहां मूल मुद्दे को देखें - एक ऐसी प्रणाली का निर्माण करना, जहां आर्किटेक्चर मॉडल सिस्टम में निम्न-स्तरीय विशेषताओं से बहुत अधिक जुड़ा हो, जिससे आर्किटेक्चर विकास प्रक्रिया में अक्सर टूट जाता है।

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

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

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

इसके लिए आपको न केवल प्रस्तावित प्रणाली की वर्तमान आवश्यकताओं को समझना होगा, बल्कि यह भी पहचानना होगा कि इसके किन पहलुओं को सिस्टम के स्थिर मूल गुणों के रूप में देखा जा सकता है, और विकास के दौरान किन गुणों के बदलने की संभावना हो सकती है।

यदि आप पाते हैं कि आपको लगातार असंगठित स्पेगेटी कोड से लड़ना है, तो आप संभवतः पर्याप्त वास्तुकला नहीं कर रहे हैं, या उच्च स्तर पर। यदि आप पाते हैं कि आपकी वास्तुकला अक्सर टूट जाती है, तो आप शायद बहुत विस्तृत वास्तुकला कर रहे हैं।

आर्किटेक्चर और डिज़ाइन पैटर्न का उपयोग कुछ ऐसा नहीं है, जिसमें आप एक सिस्टम को "कोट" कर सकते हैं, जैसे कि आप डेस्क को पेंट करेंगे। वे ऐसी तकनीकें हैं जिन्हें सोच-समझकर लागू किया जाना चाहिए, एक ऐसे स्तर पर जहां बाधाओं पर आपको भरोसा करने की आवश्यकता है, स्थिर होने की उच्च संभावना है, और जहां ये तकनीक वास्तव में वास्तुकला की संरचना और वास्तविक बाधाओं / वास्तुकला / पैटर्न को लागू करने की परेशानी के लायक हैं। कोड के रूप में।

एक बहुत विस्तृत वास्तुकला के मुद्दे पर प्रासंगिक, आप वास्तुकला में बहुत अधिक प्रयास कर सकते हैं जहां यह बहुत अधिक मूल्य नहीं दे रहा है। संदर्भ के लिए जोखिम चालित वास्तुकला देखें, मुझे यह पुस्तक पसंद है - बस पर्याप्त सॉफ्टवेयर वास्तुकला , शायद आप भी।

संपादित करें

मेरे जवाब को स्पष्ट करने के बाद से मैंने महसूस किया कि मैंने अक्सर खुद को "बहुत अधिक वास्तुकला" के रूप में व्यक्त किया, जहां मुझे वास्तव में "बहुत विस्तृत वास्तुकला" का मतलब था, जो बिल्कुल वैसा नहीं है। बहुत विस्तृत वास्तुकला को अक्सर "बहुत अधिक" वास्तुकला के रूप में देखा जा सकता है, लेकिन भले ही आप वास्तुकला को अच्छे स्तर पर रखते हैं और सबसे सुंदर प्रणाली बनाते हैं जिसे मानव जाति ने कभी देखा है, यह अभी भी वास्तुकला पर बहुत अधिक प्रयास हो सकता है यदि प्राथमिकताएं हैं सुविधाओं और बाजार के लिए समय पर।

Comments

+1 ये बहुत उच्च स्तर के बारे में बहुत अच्छी तरह से विचार हैं मुझे लगता है कि आपको एक सिस्टम में दिखना चाहिए, लेकिन जैसा कि आपने कहा, इसके लिए सॉफ़्टवेयर डिज़ाइन में बहुत अनुभव की आवश्यकता होती है।

— सैमुअल

Answer 7

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

चूंकि दो अलग-अलग समस्या क्षेत्र हैं, तकनीकी और पारस्परिक, मैं प्रत्येक को अलग से संबोधित करूंगा।

पारस्परिक

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

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

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

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

तकनीकी

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

(जो निम्नलिखित तकनीकी समाधानों का एक सेट है, जो मूल प्रश्न में नहीं पूछे गए थे, लेकिन यह दर्शाता है कि हम कैसे चित्रण के उद्देश्यों के लिए पैटर्न का पालन कर सकते हैं।)

अशक्त वस्तु के पीछे का सिद्धांत अलग-अलग होता है । हम छिपाते हैं कि हमें किन बदलावों से निपटना है और हर जगह इसका सामना नहीं करना पड़ेगा। यहाँ, अशक्त वस्तु product.Priceउदाहरण में विचरण को एनकैप्सुलेट कर रही थी (मैं इसे एक Priceवस्तु कहूंगा , और एक अशक्त वस्तु की कीमत होगी NullPrice)। Priceएक डोमेन ऑब्जेक्ट, एक व्यवसाय अवधारणा है। कभी-कभी, हमारे व्यावसायिक तर्क में, हम अभी तक कीमत नहीं जानते हैं। ऐसा होता है। अशक्त वस्तु के लिए सही उपयोग का मामला। Prices में एक ToStringविधि है जो मूल्य, या खाली स्ट्रिंग को आउटपुट करती है अगर यह ज्ञात नहीं है (या, NullPrice#ToStringएक खाली स्ट्रिंग लौटाता है)। यह एक उचित व्यवहार है। फिर जरूरतें बदल जाती हैं।

हमें nullएपीआई दृश्य या प्रबंधकों के दृष्टिकोण के लिए एक अलग स्ट्रिंग का उत्पादन करना होगा। यह हमारे व्यावसायिक तर्क को कैसे प्रभावित करता है? खैर, यह नहीं है। उपर्युक्त कथन में, मैंने दो बार 'दृश्य' शब्द का प्रयोग किया। यह शब्द शायद स्पष्ट रूप से नहीं बोला गया था, लेकिन हमें आवश्यकताओं में छिपे हुए शब्दों को सुनने के लिए खुद को प्रशिक्षित करना चाहिए। तो 'दृश्य' इतना क्यों मायने रखता है? क्योंकि यह हमें बताता है कि परिवर्तन वास्तव में कहां हुआ है: हमारे विचार में।

एक तरफ : हम एक एमवीसी ढांचे का उपयोग कर रहे हैं या नहीं, यहां अप्रासंगिक है। जबकि MVC का 'व्यू' के लिए बहुत विशिष्ट अर्थ है, मैं इसे अधिक सामान्य (और शायद अधिक लागू) प्रस्तुति कोड के अर्थ में उपयोग कर रहा हूं।

इसलिए हमें वास्तव में इसे देखने की जरूरत है। हम ऐसा कैसे कर सकते थे? ऐसा करने का सबसे आसान तरीका एक ifबयान होगा। मुझे पता है कि अशक्त वस्तु को सभी इफ्स से छुटकारा पाने का इरादा था, लेकिन हमें व्यावहारिक होना चाहिए। हम यह देखने के लिए स्ट्रिंग की जाँच कर सकते हैं कि क्या यह खाली है, और स्विच करें:

if(product.Price.ToString("c").Length == 0) { // one way of many
    writer.write("Price unspecified [Change]");
} else {
    writer.write(product.Price.ToString("c"));
}

यह एनकैप्सुलेशन को कैसे प्रभावित करता है? यहाँ सबसे महत्वपूर्ण हिस्सा यह है कि व्यू लॉजिक को दृश्य में समझाया जाता है । हम अपने व्यापार तर्क / डोमेन ऑब्जेक्ट को इस तरह से व्यू लॉजिक में बदलाव से पूरी तरह अलग-थलग रख सकते हैं। यह बदसूरत है, लेकिन यह काम करता है। हालांकि यह एकमात्र विकल्प नहीं है।

हम कह सकते हैं कि हमारे व्यापार तर्क में थोड़ा बदलाव आया है, अगर हम कोई मूल्य निर्धारित नहीं करते हैं तो हम डिफ़ॉल्ट स्ट्रिंग्स को आउटपुट करना चाहते हैं। हम अपनी Price#ToStringविधि के लिए एक मामूली मोड़ कर सकते हैं (वास्तव में एक अतिभारित विधि बना सकते हैं)। हम एक डिफ़ॉल्ट रिटर्न मान स्वीकार कर सकते हैं और वापस लौट सकते हैं यदि कोई मूल्य निर्धारित नहीं है:

class Price {
    ...
    // A new ToString method
    public string ToString(string c, string default) {
        return ToString(c);
    }
    ...
}

class NullPrice {
    ...
    // A new ToString method
    public string ToString(string c, string default) {
        return default;
    }
    ...
}

और अब हमारा व्यू कोड बन गया है:

writer.write(product.Price.ToString("c", "Price unspecified [Change]"));

सशर्त चला गया है। हालांकि, ऐसा करने से आपके डोमेन ऑब्जेक्ट्स में विशेष केस विधियों का प्रसार हो सकता है, इसलिए यह केवल तभी समझ में आता है जब इसके कुछ ही उदाहरण होंगे।

हम इसके बजाय एक IsSetविधि बना सकते हैं जो Priceएक बूलियन लौटाती है:

class Price {
    ...
    public bool IsSet() {
        return return true;
    }
    ...
}

class NullPrice {
    ...
    public bool IsSet() {
        return false;
    }
    ...
}

तर्क देखें:

if(product.Price.IsSet()) {
    writer.write(product.Price.ToString("c"));
} else {
    writer.write("Price unspecified [Change]");
}

हम दृश्य में सशर्त की वापसी देखते हैं, लेकिन अगर कीमत निर्धारित की जाती है, तो व्यापार तर्क के लिए मामला मजबूत होता है। हम Price#IsSetकहीं और उपयोग कर सकते हैं जो हमारे पास उपलब्ध है।

अंत में, हम मूल्य को पूरी तरह से सहायक के रूप में देखने के लिए प्रस्तुत करने के विचार को समाप्त कर सकते हैं। यह सशर्त छिपाएगा, जबकि हम जितना चाहें डोमेन ऑब्जेक्ट को संरक्षित करेंगे:

class PriceStringHelper {
    public PriceStringHelper() {}

    public string PriceToString(Price price, string default) {
        if(price.IsSet()) { // or use string length to not change the Price class at all
           return price.ToString("c");
        } else {
            return default;
        }
    }
}

तर्क देखें:

writer.write(new PriceStringHelper().PriceToString(product.Price, "Price unspecified [Change]"));

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

Answer 8

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

आवश्यकताओं में दस्तावेज़ भिन्नता अंक (वे जोखिम हैं)

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

यदि आपकी आवश्यकताएं इतनी अस्थिर हैं कि आपके "पूर्वानुमानित रूपांतर" हमेशा गलत होते हैं, तो आपके द्वारा लागू किए गए पैटर्न आपको दर्द का कारण होंगे या सबसे अच्छी तरह से अनावश्यक जटिलता होगी।

क्रेग लर्मन प्रोटेक्टिव वेरिएशन लगाने के दो अवसरों की बात करते हैं:

• भिन्नता बिंदु - मौजूदा, वर्तमान प्रणाली या आवश्यकताओं में, जैसे कि कई इंटरफेस जो समर्थित होने चाहिए, और
• विकास के बिंदु - भिन्नता के सट्टा बिंदु जो मौजूदा आवश्यकताओं में मौजूद नहीं हैं।

दोनों को डेवलपर्स द्वारा प्रलेखित किया जाना चाहिए, लेकिन आपके पास भिन्नता बिंदुओं के लिए ग्राहक की प्रतिबद्धता होनी चाहिए।

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

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

CONSTANTS स्रोत कोड में पीवी का एक सरल रूप है

आपके प्रश्न का एक अन्य सादृश्य यह पूछना होगा कि क्या CONSTANTSसोर्स कोड का उपयोग करना एक अच्छा विचार है। इस उदाहरण का उल्लेख करते हुए , मान लीजिए कि ग्राहक को पासवर्ड की आवश्यकता कम हो गई है। इस प्रकार MAX_PASSWORD_SIZEआपके कोड में एक निरंतर फैलाव बेकार हो जाएगा और रखरखाव और सुगमता के लिए एक बाधा भी बन जाएगा। क्या आप CONSTANTSइसके कारण के रूप में उपयोग को दोष देंगे ?

Answer 9

मुझे लगता है कि यह कम से कम आंशिक रूप से आपकी स्थिति की प्रकृति पर निर्भर करता है।

आपने लगातार बदलती आवश्यकताओं का उल्लेख किया है। यदि ग्राहक कहता है कि "मैं चाहता हूं कि यह मधुमक्खी पालन आवेदन भी ततैया के साथ काम करे" तो यह उस तरह की स्थिति की तरह लगता है जिसमें सावधानीपूर्वक डिजाइन प्रगति में मदद करेगा, न कि इसमें बाधा डालना (विशेषकर जब आप समझते हैं कि भविष्य में वह ऐसा करना चाहता है। फल-मक्खियों को भी रखें।)

दूसरी ओर, यदि परिवर्तन की प्रकृति अधिक है जैसे "मैं इस मधुमक्खी पालन आवेदन को अपने लॉन्ड्रोमैट समूह के पेरोल का प्रबंधन करना चाहता हूं", तो कोड की कोई भी राशि आपके छेद से बाहर नहीं निकलेगी।

डिज़ाइन पैटर्न के बारे में कुछ भी अच्छा नहीं है। वे किसी भी अन्य उपकरण की तरह हैं - हम केवल मध्यम से लंबे समय में हमारे काम को आसान बनाने के लिए उनका उपयोग करते हैं। यदि एक अलग उपकरण (जैसे संचार या अनुसंधान ) अधिक उपयोगी है तो हम उसका उपयोग करते हैं।