💗 🎸 🐚 कार्यात्मक प्रोग्रामिंग के संदर्भ में कमान और रणनीति पैटर्न 🦕 🍐 🌔

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

डिजाइन पैटर्न और कार्यात्मक प्रोग्रामिंग? यह भी कैसे संबंधित है?

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

लयात्मक विषयांतर: वास्तुकला, डिजाइन और कार्यान्वयन के बीच का अंतर

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

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

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

उच्चतर कार्य

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

let f = (+) 10 let g = (*) 2 let composition = f << g printfn "%i" <| g 15 printfn "%i" <| f 30 printfn "%i" <| composition 15

निष्कर्ष:

 30 40 40

जाहिर है, संकेतन f << g संकेतन f (g (x)) या F ○ जी से मेल खाता है।
इसे बेहतर ढंग से समझने के लिए, मैं रचना ऑपरेटर के प्रकार पर ध्यान देने का सुझाव देता हूं:

 ('a -> 'b) -> ('c -> 'a) -> 'c -> 'b

कोष्ठकों में फ़ंक्शन के प्रकार के विवरण के भाग भी प्रकार के कार्य हैं। यही है, यह एक ऐसा कार्य है जो तर्क के रूप में लेता है:

एक फ़ंक्शन जो जेनेरिक प्रकार के मान को 'एक तर्क के रूप में लेता है और जेनेरिक प्रकार' b का मान देता है
एक फ़ंक्शन जो जेनेरिक प्रकार के सी के मान को एक तर्क के रूप में लेता है और जेनेरिक प्रकार के मान को लौटाता है 'ए
मूल्य का प्रकार 'सी

और 'b' प्रकार का मान लौटाता है। वास्तव में, यह एक फ़ंक्शन का निर्माण करता है जो एक तर्क के रूप में 'c' का मान लेता है और 'b' का मान लौटाता है, अर्थात प्रकार इस तरह से फिर से लिखा जा सकता है:

 ('a -> 'b) -> ('c -> 'a) -> ('c -> 'b)

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

 private void CalculateAdditionalQuantityToIncreaseGain() { //  var unitPrice = ExtractDecimal(gainUnitPriceEdit); var quantityReleased = ExtractDecimal(gainQuantityEdit); ... }

और यहाँ FEP है जो अपवादों को संभालता है:

 private static void ExecuteErrorProneCode(Action procedure) { try { procedure(); //      } catch (WrongDecimalInputInTextBoxException ex) { MessageBox.Show(ex.Message, "  "); } catch (Exception ex) { MessageBox.Show(ex.Message, ""); } }

फिर, किसी भी फ़ंक्शन के कारण अपवादों को संभालने के लिए, यह लिखना पर्याप्त है:

 ExecuteErrorProneCode(CalculateAdditionalQuantityToIncreaseGain);

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

कमांड पैटर्न

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

विभिन्न प्राप्तकर्ताओं के लिए अनुरोध भेजें
टीमों को पंक्तिबद्ध करें, लॉग रखें, अनुरोध रद्द करें
सरल से जटिल ऑपरेशन बनाएं
पूर्ववत करें (अंतिम क्रिया को पूर्ववत करें) और फिर से करें (पिछले पूर्ववत किए गए कार्यों को दोहराएं) कमांड

सामान्य तौर पर, यह इस तरह दिखता है:

मैं पूर्ववत और फिर से लागू करने के साथ एक उदाहरण पर विचार करूंगा - आप इस कार्यक्षमता के कार्यान्वयन का एक साफ OO संस्करण देख सकते हैं।
इस आरेख में भूमिका वितरण:

यहाँ फ़िल्टर रिसीवर के y, लॉगिंगइन्कोवर - इनोकर 'y, IFilterCommand - ICommand से मेल खाता है । इस तरह से हम ऑपरेशंस को कॉल करेंगे (आप क्लाइंट ई में दोनों कमांड बना सकते हैं, उन्हें एग्जिक्यूट Execute() लॉगिंगइन्कोवर की विधि के लिए एक पैरामीटर के रूप में पास कर सकते हैं और लॉगिंगइन्कोवर ई-खुद में - चुनाव विशिष्ट स्थिति पर निर्भर करता है):

और यहां बताया गया है कि हम उन्हें कैसे रद्द करेंगे:

PerformOps और undoneOps स्टैक हैं जो निष्पादित और रद्द की गई टीमों को स्टोर करते हैं।
हालांकि, FEP पर विचार करने के बाद, यह बिल्कुल स्पष्ट है कि यह सभी व्यवहार FEP के रूप में लागू किया जा सकता है, यदि चयनित भाषा इस सुविधा का समर्थन करती है। वास्तव में, Invoker ऑब्जेक्ट को FPF द्वारा प्रतिस्थापित किया जा सकता है, जो एक विशेष ऑपरेशन के अनुरूप एक फ़ंक्शन के रूप में लेता है - हमें अब कमांड ऑब्जेक्ट की आवश्यकता नहीं है, क्योंकि फ़ंक्शन स्वयं मान हैं, और ICommand इंटरफ़ेस, क्योंकि इसके कार्यों को भाषा के प्रकार की एक प्रणाली द्वारा किया जाता है जो एक कार्यात्मक प्रतिमान का समर्थन करता है।
इस पैटर्न को एक कार्यात्मक प्रतिमान में एक डिजाइन के साथ बदलने का एक आरेख है जो समान कार्य कर सकता है:

Pseudocode (F # से प्रेरित) पर, संबंधित कार्यात्मक कार्यान्वयन इस तरह दिखेगा:

 //      //    -       type OpType = (DataType -> DataType) * DataType //      let performedOps = Stack<OpType>() let undoneOps = Stack<OpType>() // LoggingInvoker -  let execute operation data = let res = operation data //  performedOps.Push(operation, data) //       res //    let undo () = if performedOps.Count > 0 then //          undoneOps.Push(performedOps.Pop()) //      Some (snd undoneOps.Peek()) //     'a option, . (5)  (7) else None // let OperationOne data = ... let OperationTwo data = ... //  OperationOne let mutable a = execute OperationOne data //  let b <- undo ()

हम उस फ़ंक्शन में पास होते हैं जिसे हम निष्पादित करना चाहते हैं, एफवीपी execute । execute फ़ंक्शन पूर्ण किए गए कार्यों के ढेर का नेतृत्व करता है, ऑपरेशन करता है, और इसके निष्पादन का परिणाम देता है। पूर्ववत कार्य निष्पादित किए गए अंतिम ऑपरेशन को रद्द कर देता है।

कमांड पैटर्न का उपयोग करने पर इस दृष्टिकोण के कुछ अतिरिक्त लाभ हैं:

परिणामी कोड अधिक प्राकृतिक, छोटा और सरल है।
आप आसानी से रचना या पाइप-लाइनिंग (पाइप-लाइनिंग देखें (5) या (7)) ऑपरेशन का उपयोग करके मैक्रो और जटिल ऑपरेशन बना सकते हैं
आप जटिल डेटा संरचनाएं बना सकते हैं जिनमें ऑपरेशन होते हैं, उदाहरण के लिए, गतिशील रूप से मेनू बनाने के लिए।

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

रणनीति पैटर्न

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

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

छद्म कोड पर:

 let strategyA data = ... let strategyB data = ... let useStrategy strategy data = ... strategy data ... useStrategy strategyA data

फ़ंक्शंस strategyA , strategyB , ... ऐसे फ़ंक्शंस हैं जो संभावित रणनीतियों को लागू करते हैं। उच्च क्रम फ़ंक्शन का useStrategy डेटा में चयनित रणनीति को लागू करता है। स्ट्रैटेजी का उपयोग करने के लिए एक रणनीति के रूप में रणनीति को पारित किया जाता है।
कोड को बहुत सरल और छोटा करने के अलावा, यह दृष्टिकोण हमें एक अतिरिक्त लाभ देता है - अब हम आसानी से एक बार में कई रणनीतियों द्वारा पैरामीटर किए गए कार्यों को बना सकते हैं, जो सामान्य ओओ दृष्टिकोण के साथ, एक बहुत ही जटिल प्रोग्राम संरचना की ओर जाता है। अनाम कार्यों के रूप में इस तरह के अवसर की मदद से हमें रणनीतियों के लिए अलग-अलग नामों को निर्दिष्ट करने की आवश्यकता नहीं हो सकती है, यदि वे लागू करने के लिए पर्याप्त सरल हैं। उदाहरण के लिए, FI में डेटा को सॉर्ट करने के लिए, आप FVP सॉर्ट का उपयोग कर सकते हैं और इसे टाइप नहीं कर सकते हैं जो IComparer इंटरफ़ेस को लागू करता है, जो तुलना विधि को लागू करता है, जैसा कि OOP में किया जाता है, लेकिन केवल तुलना ऑपरेशन से ही होता है।

 let a = sort (<) data

निष्कर्ष

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

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

सूत्रों का कहना है

1. आपराधिक अतिरंजना
2. वास्तुकला, डिजाइन, कार्यान्वयन । एमोन एच। ईडन, रिक कज़मैन। पोर्टलैंड: B.Sc. 2003. सॉफ्टवेयर इंजीनियरिंग पर 25 वां अंतर्राष्ट्रीय सम्मेलन - ICSE
3. बैंकिंग फर्म 50 प्रतिशत तक गति विकास के लिए कार्यात्मक भाषा का उपयोग करती है। Microsoft केस स्टडीज। मार्च 2010
4. बिशप, जुडिथ। सी # 3.0 डिजाइन पैटर्न। सेबेस्टोपोल, कैलिफोर्निया: ओ'रेली, 2008।
5. टॉमस पेट्रिसक, जॉन स्कीट। वास्तविक दुनिया के लिए कार्यात्मक प्रोग्रामिंग। बी.एम.: मैनिंग प्रकाशन, 2010।
6. गेब्रियल, रिचर्ड पी। ऑब्जेक्ट्स फेल्ड स्लाइड्स ड्रीमगोंग्स।
7. स्मिथ, क्रिस। प्रोग्रामिंग एफ #। सेबेस्टोपोल, कैलिफोर्निया: ओ'रेली, 2010।

यूडीपी:
alexeyrom ने एक बहुत ही उपयोगी टिप्पणी लिखी, उनकी सहमति से मैंने इसे पोस्ट की बॉडी में डाला ताकि इसे देखा जा सके:

“नॉरविग ने 1996 में लिस्प और डायलन में पैटर्न देखा । वास्तव में, परिणाम समान है (कई पैटर्न तुच्छ या काफी सरल हो जाते हैं), लेकिन समृद्ध सामग्री पर। ”

कार्यात्मक प्रोग्रामिंग के संदर्भ में कमान और रणनीति पैटर्न