भाषाओं के निर्माण के लिए डिज़ाइन पैटर्न क्यों नहीं जोड़े गए हैं?

Question

हाल ही में मैं एक सहकर्मी के साथ बात कर रहा था, जिसने उल्लेख किया कि उनकी कंपनी एमवीसी डिज़ाइन पैटर्न को एक PHP एक्सटेंशन के रूप में जोड़ने पर काम कर रही थी।

उन्होंने बताया कि उन्होंने Controllers, Models and Viewsप्रदर्शन बढ़ाने के लिए भाषा निर्माण में जोड़ने के लिए सी कोड लिखा ।

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

IMHO डिजाइन पैटर्न को एक भाषा में एकीकृत करने से अच्छे OO डिजाइन के महत्व पर जोर दिया जा सकता है।

तो, सबसे अधिक इस्तेमाल किए जाने वाले डिज़ाइन पैटर्न (MVC, फ़ैक्टरी, रणनीति, ... आदि) भाषा के निर्माण में क्यों नहीं जोड़े गए हैं?

यदि प्रश्न बहुत व्यापक लगता है तो आप प्रश्न को केवल PHP तक सीमित कर सकते हैं।

संपादित करें:

मैं यह नहीं कह रहा हूँ कि किसी प्रोजेक्ट को विकसित करते समय एक डिज़ाइन पैटर्न का उपयोग करना चाहिए । वास्तव में जब तक यह काम करता है मैं इसे सरल रखने की पद्धति को बढ़ावा देता हूं।

Comments

विचार की एक पाठशाला है जो कहती है कि कई पैटर्न होने से एक भाषा गंध है। निश्चित रूप से GO4 पुस्तक में कई पैटर्न गायब हो जाते हैं या लिस्प में 1 लाइनर बन जाते हैं।

— ज़ाचरी के

"बिल्डिंग फैक्ट्रीज़ किसी भी प्रोजेक्ट में 100% गारंटी है।" फिर आपने बुरे प्रोजेक्ट्स पर काम किया। जबकि कारखाना उपयोगी पैटर्न है, यह गारंटी से दूर है। किसी भी ओओपी में फैक्टरी पैटर्न होता है। इसे कंस्ट्रक्टर कहा जाता है।

— युफोरिक

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

— SK- तर्क

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

— रेयान

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

— ब्लूराजा - डैनी पफ्लुगुएफ्ट

Answer 1

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

लूप डिजाइन पैटर्न के बारे में क्या ? जबकि लूप डिजाइन पैटर्न? स्विच डिजाइन पैटर्न? वस्तु डिजाइन पैटर्न? कक्षा डिजाइन पैटर्न? इन सभी को कुछ भाषाओं में जोड़ा गया है।

Comments

दरअसल, सबरूटीन कॉल के लिए मिश्रित डिज़ाइन पैटर्न सामान्य थे (कोडांतरक और मशीन कोड में, कम से कम) अच्छी तरह से 50 के दशक के अंत में, 60 के दशक की शुरुआत में और M6800 (8-बिट एक) में भी प्रदर्शित किए गए थे। के लिए खोज Wheeler jumpया Modified Wheeler jump।

— वैटीन

TI-83 Plusमूल भाषा में इस तरह के निर्माण की अनुपस्थिति ने एक समान पैटर्न को वापस ले लिया जब मैं 2001 के आसपास प्रोग्राम करना सीख रहा था।

— इजाका

Answer 2

उनमें से कुछ हैं। उदाहरण के लिए पुनरावृत्तियों कई भाषाओं में भाषा की विशेषता है और उनके मानक पुस्तकालयों (वहाँ, foreach और उपज वापसी)। प्रेक्षक भी अक्सर घटनाओं के रूप में मौजूद होते हैं (PHP में नहीं - आपको खुद कॉलबैक सदस्यता का प्रबंधन करना होगा)। WPF में कमांड मुख्य विशेषता है।

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

MVC का एकमात्र घटक जो IMO किसी प्रकार की भाषा के समर्थन से लाभान्वित हो सकता है देखें (कुछ आधिकारिक अस्थायी इंजन के साथ) - और यह PHP में पहले से ही समर्थित है - आप PHP स्क्रिप्ट्स को गतिशील रूप से बनाने और लोड करने में सक्षम हैं (जो अक्सर साथ होते हैं कुछ प्रकार के प्रीप्रोसेसिंग को टेम्प्लेट के रूप में उपयोग किया जाता है)।

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

Comments

यहां तक ​​कि ऑब्जेक्ट ओरिएंटेशन को एक विशेष पैटर्न के रूप में सोचा जा सकता है जिसे उपयोगी माना गया और इसलिए कई भाषाओं में बेक किया गया। सामान्य तौर पर, एक पैटर्न की उपस्थिति भाषा की सुविधा की कमी का एक संकेतक है।

— एंड्रिया

Answer 3

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

लेकिन सवाल पर ध्यान केंद्रित करने के लिए - कई कारण हैं कि आप एक भाषा में बहुत सारे डिजाइन पैटर्न क्यों नहीं जोड़ना चाहेंगे:

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

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

Answer 4

भाषा के निर्माण में सबसे अधिक उपयोग किए जाने वाले डिज़ाइन पैटर्न (MVC, फ़ैक्टरी, रणनीति, आदि) क्यों नहीं हैं?

इनमें से अधिकांश पैटर्न विशिष्ट भाषाई समर्थन के बिना अधिकांश प्रोग्रामिंग भाषाओं में लागू किए जा सकते हैं। उदाहरण के लिए जावा में MVC लें:

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

इन सभी विकल्पों को देखते हुए, सीधे भाषा का विस्तार करने में बहुत कम मूल्य है। और "डाउनसाइड्स" की एक संख्या हैं:

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

Answer 5

वो हैं।

सी में भाषा निर्माण होने से पहले फ़ंक्शंस असेंबली कोड में एक डिज़ाइन पैटर्न थे।

वर्चुअल फ़ंक्शंस C में एक डिज़ाइन पैटर्न थे, इससे पहले कि वे C ++ में एक लैंगिएज निर्माण बन गए।

हालाँकि, एक व्यापार बंद है। यदि पैटर्न में बॉयलरप्लेट कोड (यहां तक ​​कि कुछ कीवर्ड) का उत्पादन शामिल है, तो यह एक संकेत है कि यह एक उपयोगी भाषा सुविधा होगी। लेकिन अगर पैटर्न सरल और स्पष्ट है, उदाहरण के लिए। C की "for (int i = 0; i <10; i ++)", यह अभी भी हर किसी के लिए इसे उसी तरह से लिखना उपयोगी है, लेकिन यह "i = 0 से 10" की तुलना में अधिक लंबा नहीं है और इसका महत्वपूर्ण लाभ यह है कि स्पष्ट है कि इसे थोड़ा अलग लूप बनाने के लिए कैसे बदलना है।

Answer 6

'गैंग ऑफ़ फोर' किताब पढ़ें और यह स्पष्ट हो जाएगा कि:

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

Answer 7

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

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

Answer 8

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

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

दूसरी ओर Iterator एक उच्च सामान्य अवधारणा है जिसे बहुत विस्तृत विविधता में कई प्रकार के निर्माणों में लागू किया जा सकता है।

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