कार्यात्मक प्रोग्रामिंग में ऐसा क्या है जिससे फर्क पड़ता है?
फंक्शनल प्रोग्रामिंग सिद्धांत घोषणात्मक द्वारा होता है । आप कहते हैं कि इसके बजाय आपका परिणाम क्या है, इसकी गणना कैसे करें।
आइए आपके स्निपेट के वास्तव में कार्यात्मक कार्यान्वयन पर एक नज़र डालें। हास्केल में यह होगा:
predsum pred numbers = sum (filter pred numbers)
क्या यह स्पष्ट है कि परिणाम क्या है? काफी, यह संख्या को विधेय से मिलने का योग है। इसकी गणना कैसे की जाती है? मुझे परवाह नहीं है, संकलक से पूछें।
आप संभवतः कह सकते हैं कि का उपयोग करते हुए sumऔर filterएक चाल है और यह गणना नहीं करता। फिर इन सहायकों के बिना इसे लागू करने दें (हालांकि सबसे अच्छा तरीका उन्हें पहले लागू करना होगा)।
"कार्यात्मक प्रोग्रामिंग 101" समाधान जो उपयोग नहीं करता sumहै वह पुनरावृत्ति के साथ है:
sum pred list =
case list of
[] -> 0
h:t -> if pred h then h + sum pred t
else sum pred t
यह अभी भी बहुत स्पष्ट है कि एकल फ़ंक्शन कॉल के संदर्भ में क्या परिणाम है। यह या तो 0, या recursive call + h or 0, पर निर्भर करता है pred h। अभी भी बहुत कठिन है, भले ही अंतिम परिणाम तुरंत स्पष्ट नहीं है (हालांकि थोड़ा अभ्यास के साथ यह वास्तव में forलूप की तरह ही पढ़ता है )।
अपने संस्करण की तुलना करें:
public int Sum(Func<int,bool> predicate, IEnumerable<int> numbers){
int result = 0;
foreach(var item in numbers)
if (predicate(item)) result += item;
return result;
}
इसका परिणाम क्या है? ओह, मैं देख रहा हूं: एकल returnकथन, यहां कोई आश्चर्य नहीं return result:।
लेकिन क्या है result? int result = 0? सही नहीं लगता। आप उसके साथ बाद में कुछ करें 0। ठीक है, आप itemइसे जोड़ते हैं । और इसी तरह।
बेशक, अधिकांश प्रोग्रामर के लिए यह बहुत स्पष्ट है कि इस तरह से एक साधारण कवक में क्या होता है, लेकिन कुछ अतिरिक्त returnबयान जोड़ें या यह अचानक ट्रैक करने के लिए कठिन हो जाता है। सभी कोड के बारे में है कि कैसे , और पाठक को पता लगाने के लिए क्या बचा है - यह स्पष्ट रूप से एक बहुत जरूरी शैली है ।
तो, चर और छोरों गलत हैं?
नहीं।
ऐसी कई चीजें हैं जो उनके द्वारा बहुत आसान बताई गई हैं, और कई एल्गोरिदम जिनमें परिवर्तनशील राज्य की आवश्यकता होती है तेजी से। लेकिन चर स्वाभाविक अनिवार्य कर रहे हैं, समझा कैसे के बजाय क्या है, और क्या उनके मूल्य कुछ लाइनें बाद में या कुछ पाश पुनरावृत्तियों के बाद हो सकता है की छोटी सी भविष्यवाणी दे रही है। लूप्स को आमतौर पर समझ बनाने के लिए राज्य की आवश्यकता होती है, और इसलिए वे स्वाभाविक रूप से अनिवार्य भी होते हैं।
चर और छोरों बस कार्यात्मक प्रोग्रामिंग नहीं हैं।
सारांश
समकालीन रूप से फ़नसिटिकल प्रोग्रामिंग थोड़ी अधिक शैली है और एक प्रतिमान की तुलना में सोच का एक उपयोगी तरीका है। शुद्ध कार्यों के लिए मजबूत प्राथमिकता इस मानसिकता में है, लेकिन यह वास्तव में सिर्फ एक छोटा सा हिस्सा है।
अधिकांश व्यापक भाषाएं आपको कुछ कार्यात्मक निर्माणों का उपयोग करने की अनुमति देती हैं। पायथन में उदाहरण के लिए आप इनमें से चुन सकते हैं:
result = 0
for num in numbers:
if pred(result):
result += num
return result
या
return sum(filter(pred, numbers))
या
return sum(n for n in numbers if pred(n))
ये कार्यात्मक अभिव्यक्तियाँ उस तरह की समस्याओं के लिए अच्छी तरह से फिट होती हैं और बस कोड को छोटा (और छोटा अच्छा है ) बनाती है। आपको विचारशील रूप से उनके साथ अनिवार्य कोड को प्रतिस्थापित नहीं करना चाहिए, लेकिन जब वे फिट होते हैं, तो वे लगभग हमेशा एक बेहतर विकल्प होते हैं।
itemलूप में परिवर्तनशील परिवर्तन होता है।