आजकल डिजाइन पैटर्न वास्तव में आवश्यक हैं?


107

मैं "कोडर्स एट वर्क" पढ़ रहा था और इस तथ्य का सामना किया है कि पुस्तक में साक्षात्कार किए गए कुछ पेशेवर डिज़ाइन पैटर्न के बारे में इतने उत्साही नहीं हैं।

मुझे लगता है कि इसके 2 मुख्य कारण हैं:

  1. डिजाइन पैटर्न हमें उनकी शर्तों में सोचने के लिए मजबूर करते हैं। दूसरे शब्दों में, कुछ नया (शायद बेहतर) का आविष्कार करना लगभग असंभव है।

  2. डिजाइन पैटर्न हमेशा के लिए नहीं रहते हैं। भाषाएं और प्रौद्योगिकियां तेजी से बदलती हैं; इसलिए, डिजाइन पैटर्न अंततः अप्रासंगिक हो जाएगा।

तो शायद यह सीखने के लिए और अधिक महत्वपूर्ण है कि किसी विशेष पैटर्न के बिना ठीक से कैसे प्रोग्राम करें और उन्हें न सीखें।

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


79
यदि कोई पैटर्न लागू करने का मतलब मौजूदा कोड को कॉपी करना और चिपकाना है तो आप शायद इसे गलत कर रहे हैं
Dyppl

9
डिजाइन पैटर्न का उपयोग करना! = कार्गो पंथ प्रोग्रामिंग
झकझोरना

11
इस प्रश्न का शीर्षक फिर से लिखा जा सकता है "क्या आजकल पहिया वास्तव में आवश्यक नहीं है?"
एरिक किंग

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

जवाबों:


261

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

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

और सबसे शक्तिशाली, अगर मैंने एक वर्ग का नाम रखा है FooBuilder तो आप जानते हैं कि मैं अपने फू को उत्पन्न करने के लिए बिल्डर पैटर्न का उपयोग कर रहा हूं।

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

उस अर्थ में, डिजाइन पैटर्न की शक्ति कभी नहीं मिटेगी।


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

8
हालांकि, पैटर्न भी चले जाते हैं। 1950 के दशक में, "सबरूटीन कॉल" एक बहुत लोकप्रिय पैटर्न था। सी में, "ऑब्जेक्ट" एक (कुछ हद तक) लोकप्रिय पैटर्न है। उन दोनों को अब व्यावहारिक रूप से विलुप्त कर दिया गया है क्योंकि वे आधुनिक भाषाओं में अवशोषित किए गए थे (और सबरूटीन के मामले में) आधुनिक सीपीयू के अनुदेश सेट में भी।
जोर्ग डब्ल्यू मित्तग

9
@ याकूब मर्फी: अर्घ सिंगलटन :(: (@pdr): वास्तव में, पैटर्न संचार के बारे में संचार के बारे में हैं। एक पैटर्न लागू करना क्योंकि यह लगभग फिट बैठता है सबसे बड़ी गलती एक कर सकता है, और इसलिए पैटर्न के संदर्भ में डिजाइन प्रतिबिंब नहीं किया जाना चाहिए। उन्हें केवल उस डिज़ाइन को दर्ज करना चाहिए, जब आपको यह समझाने की बात आती है कि आपने क्या सोचा था: "यह लगभग एक <पैटर्न की तरह है> सिवाय इसके कि मैंने ट्वीक किया है ..." मुझे लगता है कि बहुत ही GOF इसे खुद स्वीकार करता है: पैटर्न ट्रिम / सरल हो गए हैं सपने, वे विशेष स्थिति के लिए अनुकूलित किया जा है।
माथीउ एम

10
@ जोर्ग: जब "सबरूटिन कॉल" पैटर्न चला गया। आपको क्या लगता है कि एक विधि / फ़ंक्शन कॉल क्या है?
डंक

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

32

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

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


15

पैटर्न दो प्राथमिक उद्देश्यों की सेवा करते हैं:

  • तनावों का अनुमान लगाने से हल करना: पैटर्न एक तरह से तनाव के एक निश्चित सेट को हल करने के लिए डिज़ाइन किए गए हैं जो काम करने के लिए जाने जाते हैं। स्मॉलटॉक बेस्ट प्रैक्टिस पैटर्न के लेखक केंट बेक, पैटर्न का वर्णन एक निर्णय के रूप में दोहराते हैं जो एक विशेषज्ञ समान परिस्थितियों में करेगा। जब तक तनाव एक ही रहता है (और वे अक्सर करते हैं), पैटर्न जो उन्हें हल करते हैं उपयोगी रहेंगे।

  • संचार बल गुणक : पैटर्न हमें थोड़ा के साथ बहुत कुछ कहने की अनुमति देता है। वे शक्तिशाली, अच्छी तरह से समझी जाने वाली अवधारणाओं के एक छोटे से सेट का लाभ उठाते हैं जो विभिन्न प्रकार की समस्या वाले स्थानों में लागू होते हैं। @ pdr का जवाब पैटर्न के संचार मूल्य के बारे में मृत है।


12

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

अब, जब लोग पैटर्न के बारे में बात करते हैं तो मुझे नापसंद होता है कि कुछ लोगों को उनके साथ एक तरह का जुनून है। मेरे पास एक बार मेरे पास "कम से कम दो और पैटर्न शामिल करने के लिए" (डब्ल्यूटीएफ ?!) को पूछने के लिए एक क्लाइंट था, क्योंकि मेरे कोड में buzzwords की कमी के कारण यह पर्याप्त नहीं लगता था।


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

1
@ डॉनल फेलो यही मैंने किया :) मैंने स्पोटिंग पैटर्न ढूंढ कर उनका नामकरण किया, जिससे परियोजना को सुखद अंत मिला। मेरी सबसे बड़ी समस्या यह है कि यह एक बहुत, बहुत छोटा प्रोजेक्ट (लगभग एक सप्ताह का काम) और बहुत सीधा था: इसने एक अजीब डेटा प्रारूप से डेटा पढ़ा, कुछ रूपांतरण किए, डेटा को ग्राफ़ किया और इसे डेटाबेस में सिंक किया।
विटोर प्य

@Vitor मैं आपसे पूरी तरह सहमत हूँ। मैं व्यक्तिगत रूप से उन लोगों को जानता हूं जो सोचते हैं कि एक डिज़ाइन पैटर्न की तलाश करना जो आपकी समस्या / परिदृश्य को फिट करता है, एक बुरा विचार है! वे पहिए को फिर से लगाना पसंद करते हैं। मुझे डर है कि वे एक दिन जाग सकते हैं और मुझे जावा आईओ कक्षाओं का उपयोग न करने और अपने स्वयं के आईओ हैंडलर लिखने के लिए कह सकते हैं!
CKing

6

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

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


3
"एंटी-पैटर्न" "खराब" के लिए सिर्फ एक लंबे समय तक चलने वाला व्यंजना है।
माइकल शॉ

@hardmath "एंटी-पैटर्न" का मतलब सिर्फ 'खराब' से बहुत अधिक है
GoatInTheMachine

1
@GoatInTheMachine: मैं सहमत हूं, यह मेरी पोस्ट पर एक टिप्पणी थी। जबकि विरोधी पैटर्न इस बात के उदाहरण हैं कि किस चीज़ से बचना है, उनकी विशेषता लक्षण हैं जो उन्हें आकर्षक डिजाइन विकल्प बनाते हैं। कभी-कभी जानबूझकर एक विरोधी पैटर्न का पालन करना, इसकी कमियों और जाल को जानना, उचित है।
हार्डमैथ

4

डिज़ाइन पैटर्न दो प्रकार के होते हैं:

  1. सार्वभौमिक पैटर्न , जो जटिल कार्यक्रमों को व्यवस्थित करने के तरीके के बारे में बहुत अधिक हैं ताकि आप उन्हें बिल्कुल समझ सकें। ये दूर नहीं जा रहे हैं, हालांकि उनमें से अधिक उदाहरण खोजे जा सकते हैं।
  2. परिस्थितिजन्य पैटर्न , जो बाधाओं से प्रेरित विशेष बलों (जैसे, प्रोग्रामिंग भाषा) में इतने बंधे होते हैं कि जब वे बल बदलते हैं, तो वे अप्रासंगिक हो जाते हैं।

ठीक है, यकीनन सभी पैटर्न कुछ-कुछ स्थितिजन्य हैं, लेकिन कुछ ताकतें वास्तविक दुनिया से हैं और दूसरों के साथ बलों के उपकरण हैं। उपकरण वास्तविक दुनिया की तुलना में बहुत तेजी से बदलते हैं।


सभी पैटर्न को उस तरह से परिभाषित किया जाता है जिस तरह से वे तनाव का एक निश्चित सेट हल करते हैं। जब तक तनाव समान होते हैं (और वे अक्सर होते हैं, यही कारण है कि वे पैटर्न हैं ), पैटर्न उपयोगी रहेंगे।
रीन हेनरिक्स

@ रिन: लेकिन तनाव पैदा करने वाली ताकतें आंतरिक या बाहरी हो सकती हैं। विभिन्न भाषाओं में अलग-अलग आंतरिक बल होते हैं (उदाहरण के लिए, इंटरफ़ेस से संबंधित पैटर्न जावा के लिए C ++ की तुलना में अधिक प्रासंगिक हैं क्योंकि उनकी कक्षा प्रणालियों में अलग-अलग तनाव हैं)।
डोनाल्ड फेलो

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

3

डिज़ाइन पैटर्न के बारे में पढ़ना, उन्हें फिर से स्थापित करने के बजाय गणित सीखना है। कोई भी आपको एक निश्चित क्षेत्र में एक महान प्रगति करने से नहीं रोक रहा है एक बार जब आप पहले गए थे की एक ठोस समझ है। क्या आपको लगता है कि रिमैन यूक्लिड को कभी नहीं पढ़ता है?


1

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


1

मेरा मानना ​​है कि चार के गिरोह के रूप में डिजाइन पैटर्न वर्गीकृत करते हैं

आमतौर पर होने वाली समस्या का एक सामान्य समाधान *

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

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

इसके अलावा, .NET फ्रेमवर्क में कई श्रोताओं के लिए घटनाओं को प्रकाशित करने के लिए इवेंट मैकेनिज्म है, जो इस संदर्भ में ऑब्जर्वर पैटर्न को कम प्रासंगिक बनाता है।

डेस्कटॉप एप्लिकेशन से वेब एप्लिकेशन में परिवर्तन ** भी प्रोग्रामिंग समस्याओं के प्रकार को बदलते हैं जिन्हें हमें हल करना है। पुस्तक "डिज़ाइन पैटर्न" में कई पैटर्न डेस्कटॉप अनुप्रयोगों के लिए प्रासंगिक हैं, लेकिन वेब अनुप्रयोगों के लिए इतना नहीं है। बेशक, सिंगल पेज ऐप्स के साथ, ये पैटर्न क्लाइंट-साइड पर फिर से प्रासंगिक हो सकते हैं।

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

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

* उद्धरण 100% सटीक नहीं हो सकता है क्योंकि यह मेमोरी से लिया गया है

** मेरे अनुभव में, उद्यमों के लिए आंतरिक लाइन-ऑफ-बिजनेस अनुप्रयोगों के लिए वेब डिलीवरी तंत्र का चयन करना बहुत आम बात है।

*** कार्यात्मक प्रोग्रामिंग और कार्यात्मक डेटा संरचनाओं को सीखने के बाद, फिर वह वास्तव में जिस तरह से मैं आज इसे हल कर सकता हूं।


-3

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


2
इससे पहले किए गए बिंदुओं पर कुछ भी स्पष्ट नहीं होता है और पूर्व उत्तर में बताया गया है
gnat
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.