design patterns कहत क्या कार्यात्मक प्रोग्रामिंग गोफ डिजाइन पैटर्न को प्रतिस्थापित करता है?




पैटर्न परिभाषा (19)

जीओएफ पुस्तक स्पष्ट रूप से ओओपी से जुड़ी है - शीर्षक डिजाइन पैटर्न है - पुन: प्रयोज्य ऑब्जेक्ट-ओरिएंटेड सॉफ्टवेयर के तत्व (जोर मेरा।)

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

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

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

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

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

क्या इस दावे के लिए कोई सच है कि कार्यात्मक प्रोग्रामिंग ओओपी डिजाइन पैटर्न की आवश्यकता को समाप्त करता है? यदि ऐसा है, तो क्या आप एक विशिष्ट ओओपी डिजाइन पैटर्न और इसके कार्यात्मक समकक्ष के उदाहरण को पोस्ट या लिंक कर सकते हैं?


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

वास्तविक कार्यात्मक प्रोग्रामिंग में कोई भी स्थिति मौजूद नहीं है, इसलिए यह गोफ पैटर्न लागू करने के लिए समझ में नहीं आता है। गोफ डिजाइन पैटर्न के समान तरीके से कार्यात्मक डिज़ाइन पैटर्न नहीं हैं। प्रत्येक कार्यात्मक डिजाइन पैटर्न वास्तविकता के विपरीत कलात्मक है क्योंकि कार्य गणित के निर्माण होते हैं और वास्तविकता नहीं।

कार्यों में समय की अवधारणा की कमी होती है क्योंकि वे हमेशा वही मान वापस लौटते हैं जो वर्तमान समय है जब तक कि फ़ंक्शन पैरामीटर का हिस्सा न हो, जो "भविष्य के अनुरोधों" को पुन: संसाधित करने में वास्तव में कठिन होता है। हाइब्रिड भाषाएं उन अवधारणाओं को मिश्रित करती हैं जो भाषाओं को वास्तविक कार्यात्मक प्रोग्रामिंग भाषा नहीं बनाती हैं।

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

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

चूंकि वास्तविक कार्यात्मक प्रोग्रामिंग के लिए GoF पैटर्न आवश्यक नहीं है जिसका अर्थ यह नहीं है कि SOLID सिद्धांतों को लागू नहीं किया जाना चाहिए। सोलिड सिद्धांत किसी भी भाषा प्रतिमान से परे हैं।


भाषा और पैटर्न के बीच कड़े संबंध पर ब्रायन की टिप्पणियां इस बिंदु पर हैं,

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

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

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


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

यह पुस्तक अमेज़ॅन पर उपलब्ध है। कुछ दशकों की ओओ पृष्ठभूमि से आने पर मुझे यह बहुत जानकारीपूर्ण और उत्साहजनक पाया।


जैसा कि स्वीकृत उत्तर ने कहा, ओओपी और एफपी सभी के पास उनके विशिष्ट पैटर्न हैं।

हालांकि, कुछ पैटर्न हैं जो इतने आम हैं कि सभी प्रोग्रामिंग प्लेटफार्मों के बारे में मैं सोच सकता हूं। यहां एक (अपूर्ण) सूची है:

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

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

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

इसके अलावा, मैंने एक सामान्य एफपी भाषा, हास्केल में देखा, गोफ पैटर्न के समान कुछ है, लेकिन विभिन्न नामों के साथ। मेरी राय में यह सुझाव देता है कि वे वहां थे क्योंकि एफपी और ओओपी दोनों भाषाओं में हल करने के लिए कुछ सामान्य समस्याएं हैं।

  • मोनाड ट्रांसफार्मर और सजावटी। पूर्व मौजूदा मोनाड में अतिरिक्त क्षमता जोड़ने के लिए प्रयोग किया जाता था, बाद में किसी मौजूदा ऑब्जेक्ट को अतिरिक्त क्षमता जोड़ती थी।

अनिवार्य रूप से, हाँ !

  • जब एक पैटर्न लापता विशेषताओं (उच्च आदेश कार्यों, स्ट्रीम हैंडलिंग ...) को ultimalty कि ultimalty composition सुविधा प्रदान composition
  • बार-बार पैटर्न के कार्यान्वयन को फिर से लिखने की आवश्यकता को स्वयं को भाषा की गंध के रूप में देखा जा सकता है।

इसके अलावा, यह पृष्ठ (AreDesignPatternsMissingLanguageFeatures) एक "पैटर्न / फीचर" अनुवाद तालिका और कुछ अच्छी चर्चाएं प्रदान करता है, यदि आप खोदने के इच्छुक हैं।


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

स्काला "सिंगलटन पैटर्न" से कैसे दूर है, इस पर एक नज़र डालें: आप बस कक्षा के बजाय एक वस्तु घोषित करते हैं। एक अन्य विशेषता, पैटर्न मिलान, आगंतुक पैटर्न की झुकाव से परहेज करने में मदद करता है। यहां तुलना देखें: http://andymaleh.blogspot.com/2008/04/scalas-pattern-matching-visitor-pattern.html

और स्कैला, एफ # की तरह, ओओ-कार्यात्मक का एक संलयन है। मुझे एफ # के बारे में पता नहीं है लेकिन शायद इस तरह की विशेषताएं हैं।

क्लोजर कार्यात्मक भाषा में मौजूद हैं, लेकिन उन्हें प्रतिबंधित नहीं होने की आवश्यकता है। वे प्रतिनिधिमंडल पैटर्न के साथ मदद करते हैं।

एक और अवलोकन कोड का यह टुकड़ा एक पैटर्न लागू करता है: यह इतना क्लासिक है और यह इतना मौलिक है कि हम आमतौर पर इसे "पैटर्न" के रूप में नहीं सोचते हैं, लेकिन यह सुनिश्चित है कि:

for(int i = 0; i < myList.size(); i++) { doWhatever(myList.get(i)); }

जावा और सी # जैसी प्रभावशाली भाषाओं ने अपनाया है जो इस बात से निपटने के लिए अनिवार्य रूप से एक कार्यात्मक निर्माण है: "foreach"।


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

हालांकि, यह सही है कि अधिकांश ओओपी-विशिष्ट डिजाइन पैटर्न कार्यात्मक भाषाओं में बहुत अधिक अप्रासंगिक हैं।

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

यहां इस मुद्दे के बारे में गैंग ऑफ चार को कहना है:

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

(उपरोक्त डिजाइन पैटर्न पैटर्न, पृष्ठ 4, अनुच्छेद 3 के परिचय से उद्धरण है)

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

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

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

लेकिन निश्चित रूप से अभी भी डिजाइन पैटर्न हैं जिन्हें एफपी भाषाओं द्वारा हल नहीं किया जाता है। एक सिंगलटन के एफपी समकक्ष क्या है? (एक पल के लिए अपमानजनक है कि सिंगलेट्स आमतौर पर उपयोग करने के लिए एक भयानक पैटर्न हैं)

और यह दोनों तरीकों से भी काम करता है। जैसा कि मैंने कहा, एफपी के डिजाइन पैटर्न भी हैं, लोग आमतौर पर उनके बारे में ऐसा नहीं सोचते हैं।

लेकिन आप मोनैड भर में हो सकता है। "वैश्विक स्थिति से निपटने" के लिए डिज़ाइन पैटर्न नहीं होने पर वे क्या हैं? यह एक समस्या है जो ओओपी भाषाओं में इतना आसान है कि वहां कोई समकक्ष डिज़ाइन पैटर्न मौजूद नहीं है।

हमें "स्थिर स्थिरता बढ़ाने" या "उस सॉकेट से पढ़ने" के लिए डिज़ाइन पैटर्न की आवश्यकता नहीं है, क्योंकि यह वही है जो आप करते हैं

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

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

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

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

जब आप करी का उपयोग करते हैं, या फ़ंक्शन को दूसरे के लिए तर्क के रूप में पास करते हैं, तो रोकें और सोचें कि आप ओओपी भाषा में ऐसा कैसे करेंगे।

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

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

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

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


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

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

कार्यात्मक प्रोग्रामिंग के लिए, आप ओओ डिजाइन पैटर्न किताबें नहीं पढ़ेंगे, आप एफपी डिजाइन पैटर्न पर अन्य पुस्तकें पढ़ेंगे।

भाषा अज्ञेयवादी

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

एक ठेठ ओओपी डिजाइन पैटर्न और इसके कार्यात्मक समकक्ष?

उपरोक्त मौजूद नहीं होना चाहिए। यह ओओ कोड के रूप में पुनः लिखने वाले प्रक्रियात्मक कोड का एक टुकड़ा मांगना है। उम्म्म ... अगर मैं जावा में मूल फोरट्रान (या सी) का अनुवाद करता हूं, तो मैंने इसका अनुवाद करने से कुछ और नहीं किया है। अगर मैं इसे ओओ प्रतिमान में पूरी तरह से लिखता हूं, तो यह अब मूल फोरट्रान या सी जैसा कुछ नहीं दिखता है - यह अपरिचित होगा।

ओओ डिजाइन से कार्यात्मक डिजाइन तक कोई आसान मैपिंग नहीं है। वे समस्या को देखने के बहुत अलग तरीके हैं।

कार्यात्मक प्रोग्रामिंग (प्रोग्रामिंग की सभी शैलियों की तरह) में डिजाइन पैटर्न हैं। रिलेशनल डेटाबेस में डिज़ाइन पैटर्न हैं, ओओ में डिज़ाइन पैटर्न हैं, प्रक्रियात्मक प्रोग्रामिंग में डिज़ाइन पैटर्न हैं। सब कुछ डिजाइन पैटर्न, भवनों की वास्तुकला भी है।

डिजाइन पैटर्न - एक अवधारणा के रूप में - प्रौद्योगिकी या समस्या डोमेन के बावजूद इमारत का कालातीत तरीका है। हालांकि, विशिष्ट डिजाइन पैटर्न विशिष्ट समस्या डोमेन और प्रौद्योगिकियों पर लागू होते हैं।

हर कोई जो सोचता है कि वे क्या कर रहे हैं, डिजाइन पैटर्न को उजागर करेंगे।


मुझे लगता है कि प्रत्येक प्रतिमान एक अलग उद्देश्य प्रदान करता है और इस तरह इसकी तुलना नहीं की जा सकती है।

मैंने नहीं सुना है कि गोफ डिजाइन पैटर्न हर भाषा पर लागू होते हैं। मैंने सुना है कि वे सभी ओओपी भाषाओं पर लागू हैं । यदि आप कार्यात्मक प्रोग्रामिंग का उपयोग करते हैं तो आपके द्वारा हल की जाने वाली समस्याओं का डोमेन ओओ भाषाओं से अलग है।

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


ओओपी और एफपी के पास अलग-अलग लक्ष्य हैं, ओओपी का उद्देश्य सॉफ्टवेयर घटकों की जटिलताओं / चलती हिस्सों को समाहित करना है और एफपी का उद्देश्य सॉफ्टवेयर घटकों की जटिलता और निर्भरताओं को कम करना है, हालांकि इन 2 प्रतिमानों को 100% विरोधाभासी नहीं है और लाभ प्राप्त करने के लिए एक साथ लागू किया जा सकता है दोनों दुनिया से। यहां तक ​​कि ऐसी भाषा के साथ जो सी # जैसे कार्यात्मक प्रोग्रामिंग का मूल रूप से समर्थन नहीं करता है, यदि आप एफपी सिद्धांतों को समझते हैं तो आप कार्यात्मक कोड लिख सकते हैं, वैसे ही यदि आप ओओपी सिद्धांतों, पैटर्न और सर्वोत्तम प्रथाओं को समझते हैं तो आप एफओ # का उपयोग करके ओओपी सिद्धांतों को लागू कर सकते हैं। आपके द्वारा उपयोग की जाने वाली प्रोग्रामिंग भाषा के बावजूद, आप जिस स्थिति और समस्या को हल करने का प्रयास करते हैं, उसके आधार पर आप सही विकल्प चुनेंगे।


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


टाइप सिस्टम को लाए बिना आप इस चर्चा नहीं कर सकते हैं।

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

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

लेकिन निश्चित रूप से अभी भी डिजाइन पैटर्न हैं जिन्हें एफपी भाषाओं द्वारा हल नहीं किया जाता है। एक सिंगलटन के एफपी समकक्ष क्या है? (एक पल के लिए अपमानजनक है कि सिंगलेट्स आमतौर पर उपयोग करने के लिए एक भयानक पैटर्न हैं)

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

आप 23 की सूची में जा सकते हैं और अधिक खत्म कर सकते हैं, लेकिन मेरे पास अभी समय नहीं है।



Norvig की प्रस्तुति वे सभी गोफ पैटर्न के विश्लेषण के लिए बताती है, और वे कहते हैं कि 23 पैटर्न में से 16 पैटर्न कार्यात्मक भाषाओं में सरल कार्यान्वयन था, या बस भाषा का हिस्सा थे। तो संभवतः उनमें से कम से कम सात उनमें से एक थे) समान रूप से जटिल या बी) भाषा में मौजूद नहीं है। दुर्भाग्य से हमारे लिए, वे गणना नहीं कर रहे हैं!

मुझे लगता है कि यह स्पष्ट है कि गोफ में "क्रिएशनल" या "स्ट्रक्चरल" पैटर्न में से अधिकांश जावा या सी ++ में आदिम टाइप सिस्टम को प्राप्त करने के लिए केवल वही चाल हैं जो आप चाहते हैं। लेकिन शेष विचार करने योग्य हैं इससे कोई फर्क नहीं पड़ता कि आप किस भाषा में प्रोग्राम करते हैं।

एक प्रोटोटाइप हो सकता है; जबकि यह जावास्क्रिप्ट की मौलिक धारणा है, इसे अन्य भाषाओं में खरोंच से लागू किया जाना है।

मेरे पसंदीदा पैटर्न में से एक नल ऑब्जेक्ट पैटर्न है: किसी ऑब्जेक्ट के रूप में कुछ की अनुपस्थिति का प्रतिनिधित्व करता है जो उपयुक्त प्रकार का कुछ भी नहीं करता है। एक कार्यात्मक भाषा में मॉडल करना आसान हो सकता है। हालांकि, असली उपलब्धि परिप्रेक्ष्य में बदलाव है।


गोफ डिजाइन पैटर्न ओओ भाषाओं के लिए वर्कअराउंड रेसिपी कोडिंग कर रहे हैं जो सिमुला 67 के वंशज हैं, जैसे जावा और सी ++।

डिजाइन पैटर्न द्वारा इलाज की जाने वाली अधिकांश "ills" के कारण होते हैं:

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

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

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

निर्माण और गैर-उत्परिवर्तनीय पहुंच कार्यात्मक प्रोग्रामिंग के साथ संगत है, और ऐसे पैटर्न जो अमूर्त पहुंच या निर्माण के साथ करना है, लागू हो सकते हैं: फैक्टरी, फेकाडे, प्रॉक्सी, सजावट, आगंतुक जैसे पैटर्न।

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


और यहां तक ​​कि ओओ डिजाइन पैटर्न समाधान भी भाषा विशिष्ट हैं। डिजाइन पैटर्न सामान्य समस्याओं के समाधान हैं जो आपकी प्रोग्रामिंग भाषा आपके लिए हल नहीं करती हैं। जावा में, सिंगलटन पैटर्न एक-कुछ (सरलीकृत) समस्या हल करता है। स्कैला में, आपके पास क्लास के अलावा ऑब्जेक्ट नामक शीर्ष स्तर का निर्माण होता है। यह आलसी तत्काल है और केवल एक ही है। सिंगलटन प्राप्त करने के लिए आपको सिंगलटन पैटर्न का उपयोग करने की आवश्यकता नहीं है। यह भाषा का हिस्सा है।


कार्यात्मक प्रोग्रामिंग डिजाइन पैटर्न को प्रतिस्थापित नहीं करता है। डिजाइन पैटर्न को प्रतिस्थापित नहीं किया जा सकता है।

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


मैं जेरेमी गिब्न्स द्वारा कुछ उत्कृष्ट लेकिन कुछ घने कागजात प्लग करना चाहता हूं: "डिजाइन पैटर्न पैटर्न उच्च-आदेश डेटाटाइप-जेनेरिक प्रोग्राम" और "इटरेटर पैटर्न का सार" (दोनों यहां उपलब्ध हैं: http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/ )।

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







functional-programming