2012-08-01 21 views
7

मैंने देखा है कि स्थिर विधियां सी # से F # में अधिक लोकप्रिय लगती हैं। सी # में, आप हमेशा एक तत्व एक संग्रह करने के लिए एक उदाहरण विधि को फोन करके जोड़ेंगे:एफ # कोडिंग शैली - स्थैतिक बनाम उदाहरण विधियां

mySet.Add(elem); 

लेकिन एफ # में वहां आम तौर पर एक बराबर स्थिर विधि है:

mySet.Add(elem) 
// OR 
Set.Add elem mySet 

और मैंने देखा है नमूने में अक्सर बाद में फार्म। दोनों मुझे अर्थात् और कार्यात्मक रूप से पूरी तरह से समान दिखाई देते हैं, लेकिन सी # पृष्ठभूमि से आते हैं, उदाहरण विधि का उपयोग करके अधिक प्राकृतिक लगता है। एफ # में बेहतर शैली कौन सा है और क्यों?

+0

संबंधित: http://stackoverflow.com/q/7698133/162396 – Daniel

+0

चाल जवाब देने के लिए। –

+0

पूरे कारण कार्यात्मक प्रोग्रामिंग में निहित कई कारण हैं, और कुछ विशेष रूप से एफ #, यह जानना मुश्किल है कि इसे उचित ठहराने के लिए कहां से शुरू करना है। एक बार जब आप अपने आप को कार्यात्मक प्रोग्रामिंग से परिचित कर लेंगे तो यह स्पष्ट हो जाएगा। – Daniel

उत्तर

8

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

myHigherOrderFunction (fun (x:MyType) -> x.myFunctionAsMethod) 

लेकिन अगर यह एक स्थिर पद्धति के रूप में परिभाषित किया गया है आप लिख सकते हैं:

myHigherOrderFunction MyType.myFunctionAsMethod 

जो, और अधिक सुरुचिपूर्ण आसान है लिखो (पढ़ने के लिए भी) और लगभग एक ही वाक्यविन्यास है जब नियमित रूप से बाध्य कार्य भेजते हैं।

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

कक्षा निर्दिष्ट करने के लिए आपको एक स्थिर विधि तक पहुंचने के लिए, आप कक्षाओं को एक प्रकार के कंटेनर (जैसे मॉड्यूल या नेमस्पेस) के रूप में देख सकते हैं।

+0

एफपी शैली पर उत्कृष्ट उपयोग के मामले। और प्रोग्रामिंग ओओ शैली में, उदाहरण कार्य कम हैं। – nicolas

0

f # में कार्यात्मक भाषा अलग-अलग चर के लिए अधिक देशी है जो अपरिवर्तनीय और कार्य संचालन है। यह सी # में स्थिर तरीकों के समान कार्य करता है, लेकिन कार्यों का एक फायदा सी # विधियों के लिए है। यह आंशिक आवेदन है। आप कुछ (सभी नहीं) पैरामीटर को फ़ंक्शन करने के लिए पास कर सकते हैं और पैरामीटर के हिस्से के साथ यह फ़ंक्शन नया फ़ंक्शन होगा जो अन्य पैरामीटर की आवश्यकता है।

5

अधिकांश मानक एफ # प्रकार अपरिवर्तनीय हैं। जब अपरिवर्तनीय वस्तुओं के साथ काम करने, स्थिर तरीकों बेहतर चित्रित क्या, चल रहा है, उदाहरण के लिए:

mySet.Add(elem); 

लगता mySet तरह elem, जब एक एफ # सेट एक नया mySet वापसी होगी शामिल करने के लिए उत्परिवर्तित है। सौभाग्य से एफ # यह सुनिश्चित करने में विफल रहता है कि आप यह गलती नहीं करते हैं, फिर भी यह भ्रमित कोड की ओर जाता है। इसके विपरीत:

mySet |> Set.Add elm 

फॉर्म में अलग है और ऐसा लगता है कि यह मूल से बहुत दूर होने के बिना कुछ नया लौटाएगा।

2

जबकि एफ # में स्थिर तरीके बहुत आम हैं, मुझे लगता है कि उदाहरण विधियों घटक विकास के लिए बहुत समझदारी बनाते हैं।

कारण? एफ # मॉड्यूल सिस्टम में functors की कमी है। एसएलएल या ओकैमल जैसे एमएल के अन्य स्वादों में, आप घटकों को सरल मॉड्यूल के रूप में विकसित करते हैं। यदि आप बाद में मॉड्यूल को पैरामीटर करने का निर्णय लेते हैं, तो आप अपने स्रोत कोड को दोबारा लिखने के बिना इसे एक मजेदार में प्रचारित कर सकते हैं। एफ # में आप नहीं कर सकते।

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

संबंधित मुद्दे