क्या होगा अगर मैं सॉफ्टवेयर डिज़ाइन पैटर्न का उपयोग नहीं करूंगा? [बन्द है]

Question

अगर मैं सॉफ़्टवेयर डिज़ाइन पैटर्न का उपयोग नहीं करूंगा, तो मुझे किस तरह की समस्याओं का सामना करना पड़ सकता है? क्या आप मुझे मानक ऑब्जेक्ट-ओरिएंटेड तकनीकों का उपयोग करके डिजाइन के करीब आने की समस्याओं के बारे में बता सकते हैं?

Comments

काफी कुछ सॉफ्टवेयर डिजाइन पैटर्न काफी स्पष्ट हैं। आपको उन सभी को अच्छी तरह से जानना होगा कि आप उनका उपयोग नहीं कर रहे हैं - शायद इतनी अच्छी तरह से कि आप उनका उपयोग कर सकें!

— जेम्स मैकलेड

@JamesMcLeod के एक साइड पॉइंट के रूप में, कई "डिज़ाइन पैटर्न" बहुत स्पष्ट हैं और सभी चीजें वैसे भी होती हैं। हम उन्हें नाम क्यों देते हैं, फिर? संचार के प्रयोजनों के लिए। "मैं एक्स पैटर्न का उपयोग कर रहा हूं" में आपके समाधान को समझाने की तुलना में कहीं अधिक सिमेंटिक घनत्व है, दूसरे छोर में "ओह हाँ! मैंने भी ऐसा किया है, सिवाय इसके कि मैंने अपने चर को बुलाया ..."।

— फोशी

@AJMansfield मैंने कुछ सबसे खराब कोड देखे हैं जो डिज़ाइन पैटर्न के लिए ओवरहेनुअसिम में शामिल हैं।

— एरिक रीपेन

@EricReppen डिजाइन पैटर्न के अति प्रयोग के लिए दोष उस व्यक्ति को जिम्मेदार ठहराया जाना चाहिए जो इसे करता है। मेरे दृष्टिकोण से, मूल समस्या डिज़ाइन पैटर्न में ही नहीं है, लेकिन सामान्यीकरण (आंशिक रूप से वास्तुशिल्प निरीक्षण की कमी के कारण) और ओवर-इंजीनियरिंग (कभी-कभी समितियों-इंजीनियरों द्वारा)।

— रवांग

"डिज़ाइन पैटर्न" एक लेक्सिकॉन है, न कि एक तकनीक।

— कज़ ड्रैगन ड्रैगन

Answer 1

आप बात याद कर रहे हैं।

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

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

तो मैं बनाने की कोशिश कर रहा हूँ दो प्रमुख बिंदु:

1. आप नहीं कर सकते नहीं डिजाइन पैटर्न का उपयोग करें।
2. आपके द्वारा उपयोग की जा रही चीज़ों के नाम नहीं जानने से, आपको एक टीम में काम करने में कठिनाई होगी।

Comments

+1: बिल्कुल सही। डिज़ाइन पैटर्न ज्ञात या लोकप्रिय होने से पहले मैंने OO विकास शुरू किया। हाँ हम भी बातें आविष्कार की तरह कारखानों, एकमात्र और कुछ है कि, जब आप रणनीति पैटर्न की तरह दिखता है की एक चमकदार रोशनी प्रकार में यह पर squinted। बिंदु अब है कि मैं डिजाइन पैटर्न पता मैं जानता हूँ कि कारखानों ठीक थे, लेकिन बेहतर किया जा सकता था, Singletons बुरी तरह से किया गया था और क्या है हो सकता है किया गया है एक रणनीति पैटर्न में काफी बेहतर है, तो यह वास्तव में हो गया होता गया था एक रणनीति पैटर्न।

— बाइनरी वॉरियर

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

— बाइनरी वॉरियर

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

— मैट डी

भौतिक संरचनाओं की तुलना के लिए +1। मुझे लगता है कि यह एक घर बनाने में मदद करता है यदि आप पहले से ही जानते हैं कि एक "ट्रस" एक छत के भार का समर्थन करने के बजाय एक अच्छा ढांचा है, बजाय प्रयोग और उम्मीद के कि यह पतन नहीं करता है।

— kdgregory

Answer 2

जो लोग अतीत को याद नहीं रख सकते हैं, वे इसे दोहराने की निंदा करते हैं।

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

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

Comments

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

— रसेल

Answer 3

अगर मैं सॉफ़्टवेयर डिज़ाइन पैटर्न का उपयोग नहीं करूंगा, तो मुझे किस तरह की समस्याओं का सामना करना पड़ सकता है?

आपको कोई भी सॉफ्टवेयर न लिखने की समस्या होगी।

चर एक डिजाइन पैटर्न हैं।

तरीके एक डिजाइन पैटर्न हैं।

ऑपरेटरों - इसके अलावा, घटाव, आदि - एक डिजाइन पैटर्न हैं।

विवरण एक डिजाइन पैटर्न हैं।

मान एक डिज़ाइन पैटर्न हैं।

संदर्भ एक डिजाइन पैटर्न हैं।

भाव एक डिजाइन पैटर्न है।

कक्षाएं एक डिजाइन पैटर्न हैं।

...

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

क्या आप मुझे मानक ऑब्जेक्ट-ओरिएंटेड तकनीकों का उपयोग करके डिजाइन के करीब आने की समस्याओं के बारे में बता सकते हैं?

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

Comments

The things that you have to learn like "the singleton pattern" and so on are simply patterns that haven't (yet) been baked into whatever language you're using.- यह (लगभग) एक डिजाइन पैटर्न की परिभाषा है - एक लचीला / आसानी से पुन: प्रयोज्य कोड निर्माण का उपयोग भाषा में एक सीमा को पार करने के लिए किया जाता है, जो दूसरों के लिए संवाद करना आसान है। एक बार यह भाषा का हिस्सा होने के बाद, यह अब एक डिज़ाइन पैटर्न नहीं है।

— इज़्काता

@ इज़काता: तो आपकी स्थिति यह है कि, मान लीजिए, पर्यवेक्षक पैटर्न C # में असंभव है क्योंकि C # में प्रेक्षक पैटर्न को घटनाओं के रूप में भाषा में बनाया गया है? ये बेवकूफी है। भाषा-विशिष्ट बिट जो एक पैटर्न के लिए प्रासंगिक है, भाषा में पैटर्न को लागू करने के लिए विहित तरीका है। बेशक डिजाइन पैटर्न उन भाषाओं में इस्तेमाल किया जा सकता है जो उन्हें सीधे समर्थन करते हैं; उन्हें सीधे समर्थन देने की पूरी बात है!

— एरिक लिपर्ट

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

— इज़्काता

@ इज़काता: मैं तब उलझन में हूँ। आपने कहा था कि एक बार एक पैटर्न भाषा का हिस्सा है, यह अब एक पैटर्न नहीं है। तो क्या "प्रेक्षक पैटर्न" जावा में एक पैटर्न है लेकिन C # में एक पैटर्न नहीं है?

— एरिक लिपर्ट

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

— स्टीव जेसप

Answer 4

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

उस ने कहा, मेरे पास कोई @ @ $ आईएनजी नहीं है कि फ्लाईवेट का क्या मतलब है और मैं इसे स्वीकार करने में शर्मिंदा नहीं हूं। (एक और विकिपीडिया प्रविष्टि के लिए टिप्पणियां देखें जिससे बहुत मदद मिली)

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

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

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

Comments

फ्लाईवेट (चक्का नहीं)। विकिपीडिया लेख का पहला पैराग्राफ (और केवल पहला पैराग्राफ) पढ़ें और फिर Integer.valueOf (int) को देखें और विचार करें कि यह सामान्य मानों के लिए नए पूर्णांक बनाने से कितनी बार बचता है।

@ मिचेल्ट एंड लानत। मैंने जो कुछ भी देखा है, उससे कहीं बेहतर नरक का एक जादू कर दिया। धन्यवाद।

— एरिक रेपेन

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

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

— एरिक रेपेने

Answer 5

आपके द्वारा सामना की जाने वाली मुख्य समस्या यह है कि आप पहिया को फिर से मजबूत करेंगे । उन्हें पैटर्न कहा जाता है क्योंकि वे अक्सर और पूर्वानुमानित तरीके से दिखाई देते हैं।

Answer 6

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

Answer 7

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