चूंकि मशीन भाषा (उदाहरण के लिए 0110101000110101) , कंप्यूटर भाषा आम तौर पर अमूर्तता के उच्च रूपों में विकसित हुई है, आमतौर पर कोड को समझना आसान हो जाता है जब यह किसी समस्या पर लागू होता है। असेंबलर मशीन कोड पर एक अमूर्त था, सी असेंबलर पर एक अमूर्त था, आदि।
ऑब्जेक्ट-ओरिएंटेड डिज़ाइन हमें वस्तुओं के संदर्भ में एक समस्या को मॉडल करने की अनुमति देने में बहुत अच्छा लगता है, उदाहरण के लिए, एक विश्वविद्यालय पाठ्यक्रम पंजीकरण प्रणाली की समस्या को Courseक्लास, Studentक्लास आदि के साथ मॉडल किया जा सकता है , फिर, जब हम समाधान लिखते हैं। एक OO भाषा में, हमारे पास समान कक्षाएं हैं जिन्हें जिम्मेदारियां मिलती हैं और जो आमतौर पर डिजाइन के लिए सहायक होती हैं, खासकर कोड को संशोधित करने के लिए। यदि मैं इस समस्या को 10 स्वतंत्र टीमों को देता हूं जो इसे OO पद्धति से हल करते हैं, तो आम तौर पर 10 समाधानों में समस्या से संबंधित कक्षाएं होंगी। जब आप उन वर्गों के युग्मन और इंटरैक्शन में शामिल होने लगते हैं, तो बहुत सारे अंतर हो सकते हैं, इसलिए "शून्य प्रतिनिधित्व अंतराल" जैसी कोई चीज नहीं है।
कार्यात्मक प्रोग्रामिंग के साथ मेरा अनुभव बहुत सीमित है (कोई वास्तविक दुनिया का उपयोग नहीं है, केवल हैलो वर्ल्ड प्रकार के कार्यक्रम हैं)। मैं यह देखने में विफल हो रहा हूं कि इस तरह की भाषाएं समस्याओं के लिए एफपी समाधानों को आसानी से मैप करने की अनुमति देती हैं (कम प्रतिनिधित्वत्मक अंतराल के साथ) जिस तरह से ओओ भाषाएं करती हैं।
मैं समवर्ती प्रोग्रामिंग के संबंध में एफपी के लाभों को समझता हूं। लेकिन क्या मुझे कुछ याद आ रहा है, या एफपी एक प्रतिनिधित्वात्मक अंतर को कम करने के बारे में नहीं है (समाधानों को समझना आसान है)?
यह पूछने का एक और तरीका: क्या एक ही वास्तविक दुनिया की समस्या को हल करने वाली 10 अलग-अलग टीमों के FP कोड में बहुत समानता है?
एब्सट्रैक्शन (कंप्यूटर विज्ञान) पर विकिपीडिया से (जोर मेरा):
फ़ंक्शनल प्रोग्रामिंग लैंग्वेज आमतौर पर फ़ंक्शंस से जुड़े एब्स्ट्रैक्ट्स को प्रदर्शित करती हैं , जैसे लैम्ब्डा एब्सट्रैक्ट्स (किसी वेरिएबल के फंक्शन में टर्म बनाना), हायर-ऑर्डर फ़ंक्शंस (पैरामीटर फ़ंक्शंस), ब्रैकेट एब्स्ट्रैक्शन (किसी वेरिएबल के फंक्शन में टर्म बनाना)।
प्रतिनिधित्वात्मक अंतर को संभावित रूप से बढ़ाया जा सकता है, क्योंकि [कुछ] वास्तविक दुनिया की समस्याओं को इस तरह के सार के साथ आसानी से मॉडलिंग नहीं किया जाता है।
एक और तरीका है कि मैं प्रतिनिधित्वात्मक अंतर को कम करता हुआ समस्या के समाधान तत्वों का पता लगा रहा हूं। 0की और 1मशीन कोड में है, वापस ट्रेस करने के लिए है, जबकि बहुत कठिन है Studentवर्ग वापस ट्रेस करने के लिए आसान है। सभी OO वर्ग समस्या वाले स्थान पर आसानी से ट्रेस नहीं करते हैं, लेकिन कई करते हैं।
क्या एफपी अमूर्तता को हमेशा यह समझने की जरूरत नहीं है कि वे समस्या के किस हिस्से को हल कर रहे हैं ( गणित की समस्याओं के अलावा )?ठीक है - मैं इस हिस्से पर अच्छा हूं। कई और उदाहरणों को देखने के बाद, मैं देखता हूं कि डेटा प्रसंस्करण में व्यक्त की जाने वाली समस्या के कुछ हिस्सों के लिए एफपी अमूर्त बहुत स्पष्ट हैं।
संबंधित प्रश्न के लिए स्वीकृत उत्तर क्या यूएमएल को एक कार्यात्मक कार्यक्रम के लिए इस्तेमाल किया जा सकता है? - कहते हैं, "कार्यात्मक प्रोग्रामर के पास आरेखों का बहुत अधिक उपयोग नहीं होता है।" अगर यह यूएमएल है, तो मुझे वास्तव में परवाह नहीं है, लेकिन यह मुझे एफपी अमूर्तता को समझने / संवाद करने में आसान बनाता है, अगर कोई आरेख नहीं हैं जो व्यापक रूप से उपयोग किए जाते हैं (यह उत्तर सही है)। फिर से, एफपी उपयोग / समझ का मेरा स्तर तुच्छ है, इसलिए मुझे लगता है कि सरल एफपी कार्यक्रमों पर आरेख की कोई आवश्यकता नहीं है।
ओओ डिज़ाइन में प्रत्येक पर एन्कैप्सुलेशन (एक्सेस कंट्रोल, सूचना छिपाना) के साथ फंक्शन / क्लास / पैकेज-एब्स्ट्रक्शन के स्तर हैं, जो जटिलता को आसान बनाता है। ये ऐसे तत्व हैं जो समस्या से समाधान तक जाने और वापस आसान होने की अनुमति देते हैं।
कई जवाब बोलते हैं कि ओपी के अनुरूप एक तरह से एफपी में विश्लेषण और डिजाइन कैसे किया जाता है, लेकिन कोई भी अब तक उच्च स्तर का कुछ भी नहीं बताता है (पॉल ने कुछ दिलचस्प चीजें उद्धृत की हैं, लेकिन यह निम्न-स्तर है)। मैंने कल बहुत सारे Googling किए और कुछ दिलचस्प चर्चा की। साइमन थॉम्पसन (2004) (जोर मेरा) द्वारा रिफैक्टिंग फंक्शनल प्रोग्राम्स से निम्नलिखित है
ऑब्जेक्ट-ओरिएंटेड सिस्टम को डिजाइन करने में, यह सुनिश्चित किया जाता है कि डिजाइन प्रोग्रामिंग से पहले होगा। डिजाइन यूएमएल जैसी प्रणाली का उपयोग करके लिखा जाएगा जो कि ग्रहण जैसे उपकरण में समर्थित है। शुरुआत करने वाले प्रोग्रामर ब्लूज जैसे सिस्टम का उपयोग करके एक दृश्य डिजाइन दृष्टिकोण सीख सकते हैं। कार्यात्मक प्रोग्रामिंग के लिए समान कार्यप्रणाली पर काम FAD में बताया गया है : कार्यात्मक विश्लेषण और डिजाइन , लेकिन बहुत कम अन्य कार्य मौजूद हैं। इसके कई कारण हो सकते हैं।
मौजूदा कार्यात्मक कार्यक्रम एक पैमाने के होते हैं जिसमें डिजाइन की आवश्यकता नहीं होती है। कई कार्यात्मक कार्यक्रम छोटे हैं, लेकिन अन्य, जैसे ग्लासगो हास्केल कंपाइलर, पर्याप्त हैं।
कार्यात्मक कार्यक्रम सीधे आवेदन डोमेन को मॉडल करते हैं, इस प्रकार डिजाइन अप्रासंगिक प्रदान करते हैं। जब तक कार्यात्मक भाषाएं विभिन्न प्रकार के शक्तिशाली सार प्रदान करती हैं, यह तर्क करना मुश्किल है कि ये वास्तविक दुनिया को मॉडल करने के लिए आवश्यक सभी और केवल सार प्रदान करते हैं।
कार्यात्मक कार्यक्रमों को प्रोटोटाइप की एक विकसित श्रृंखला के रूप में बनाया गया है।
में पीएचडी थीसिस ऊपर उद्धृत , विश्लेषण और डिजाइन के तरीके (ADM) के उपयोग के लाभ मानदंड से स्वतंत्र दिए गए हैं। लेकिन एक तर्क यह दिया जाता है कि एडीएम को कार्यान्वयन प्रतिमान के साथ संरेखित करना चाहिए। यही है, OOADM OO प्रोग्रामिंग के लिए सबसे अच्छा काम करता है और इसे FP जैसे किसी अन्य प्रतिमान पर लागू नहीं किया जाता है। यहाँ एक महान उद्धरण है जो मुझे लगता है कि मैं जो निरूपण करता हूं उसे मैं प्रतिनिधित्वात्मक अंतर कहता हूं:
कोई भी तर्क दे सकता है जिसके संबंध में प्रतिमान सॉफ्टवेयर विकास के लिए सबसे अच्छा समर्थन प्रदान करता है, लेकिन सबसे अधिक प्राकृतिक, कुशल और प्रभावी विकास पैकेज प्राप्त करता है जब कोई समस्या के विवरण और कार्यान्वयन और वितरण के माध्यम से एक एकल प्रतिमान के भीतर रहता है।
यहाँ FAD द्वारा प्रस्तावित आरेखों का सेट दिया गया है:
- फ़ंक्शन निर्भरता आरेख जो इसके कार्यान्वयन में उपयोग करने वालों के साथ एक फ़ंक्शन प्रस्तुत करते हैं;
- प्रकार निर्भरता आरेख जो प्रकारों के लिए एक ही सेवा प्रदान करता है; तथा,
- मॉड्यूल निर्भरता आरेख जो सिस्टम के मॉड्यूल वास्तुकला के विचार प्रस्तुत करते हैं।
एफएडी थीसिस की धारा 5.1 में एक केस स्टडी है, जो एक फुटबॉल (सॉकर) लीग से संबंधित डेटा के उत्पादन को स्वचालित करने के लिए एक प्रणाली है। आवश्यकताएं 100% कार्यात्मक हैं, उदाहरण के लिए, इनपुट फ़ुटबॉल परिणाम, लीग टेबल, स्कोरिंग टेबल, अटेंडेंस टेबल, टीमों के बीच खिलाड़ियों का स्थानांतरण, नए परिणामों के बाद डेटा अपडेट करना, आदि। गैर-कार्यात्मक आवश्यकताओं को हल करने के लिए एफएडी कैसे काम करता है, इसका कोई उल्लेख नहीं किया गया है। इसके अलावा, यह बताते हुए कि "नई कार्यक्षमता को न्यूनतम लागत पर अनुमति दी जानी चाहिए", कुछ ऐसा जो परीक्षण करने में लगभग असंभव है।
अफसोस की बात है कि एफएडी के अलावा, मैं मॉडलिंग भाषाओं (दृश्य) के लिए कोई आधुनिक संदर्भ नहीं देखता हूं जो एफपी के लिए प्रस्तावित हैं। यूएमएल एक और प्रतिमान है, इसलिए हमें यह भूल जाना चाहिए।