2009-09-22 15 views
6

पर कार्यात्मक प्रोग्रामिंग से मैं थोड़ी देर के लिए कार्यात्मक प्रोग्रामिंग सीखने के लिए f # और Haskell का उपयोग कर रहा हूं। जब तक मैं हमारी कंपनी में एफ # अनुमोदित नहीं कर सकता, मुझे अभी भी सी # का उपयोग करना होगा। मैं अभी भी कार्यात्मक शैली में रहने की कोशिश कर रहा हूं क्योंकि मैंने कई लाभ देखा है।ओओ से 10,000 फीट

यहां एक सामान्य समस्या है।

  1. 3 कुंजी (65 लाख पंक्तियाँ) के साथ डेटाबेस में एक महत्वपूर्ण सेट टेबल है
  2. 4 अन्य सहायक मध्यम आकार के लिए छोटे से टेबल रहे हैं।
  3. कई इनपुट के आधार पर जटिल सूत्र हैं।

मुझे उपरोक्त सभी से डेटा की गणना करने के लिए डेटा का उपयोग करना होगा और इसे प्रत्येक कुंजी-सेट पंक्ति से संबद्ध करना होगा और उसे डेटाबेस में वापस भेजना होगा। अन्य 4 टेबलों के लिए बहुत सारे लुकअप हैं। प्रदर्शन के लिए यह सब स्मृति में किया जाता है।

मुझे पता है कि मैं स्थिर शब्दकोश, ऑब्जेक्ट मॉडल, रणनीति पैटर्न और इतने आगे के साथ ओओ में कैसे करूँगा लेकिन एक कार्यात्मक तरीके से मैं इन संरचनाओं में से कुछ का उपयोग करने की बुरी गंध से छुटकारा नहीं पा सकता हूं।

मैं वर्तमान में एक कार्यात्मक समाधान के लिए निम्नलिखित मान्यताओं को बना रहा हूं।

  1. स्टेटिक शब्दकोश खराब हैं। ऐसा लगता है कि समारोह पक्ष को प्रभावित कर सकता है।

  2. मुझे एक गणना करने की आवश्यकता है जो एक अपरिवर्तनीय वस्तु लेता है और तीन कुंजियों और गणना मूल्य के साथ एक अपरिवर्तनीय वस्तु देता है। इस समारोह के अंदर एक ही शैली में एक और कार्य हो सकता है।

  3. पारंपरिक ओओ पैटर्न शायद काम नहीं करेंगे।

आप इसे उच्च स्तर पर कैसे डिजाइन करेंगे?

क्या मैं गलत हूँ? क्या मुझे कुछ याद आया है?

उत्तर

6

नहीं, आप गलत नहीं हैं। ओओपी और कार्यात्मक प्रोग्रामिंग दोनों में उनके लाभ और उनकी कमी है।

एक डेवलपर को यह पता होना चाहिए कि प्रत्येक विकास शैली का उपयोग कैसे करें और कब करें। यह भाग्यशाली है कि सी # विकास शैली दोनों तरह से समर्थन करता है।

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

मैं आम तौर पर अपने डोमेन (इकाइयों, समेकित, मूल्य वस्तुओं, भंडारों और घटनाओं) पर ऑब्जेक्ट उन्मुख प्रोग्रामिंग का उपयोग करता हूं और मेरी सेवा वस्तुओं के लिए आरक्षित कार्यात्मक प्रोग्रामिंग का उपयोग करता हूं।

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

0

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

Blockquote 1. स्टेटिक शब्दकोशों बुरा कर रहे हैं। ऐसा लगता है कि समारोह पक्ष को प्रभावित कर सकता है।

या तो यह दुष्प्रभाव नहीं करता है या नहीं। ओओ भाषा में ज्ञापन को लागू करने के लिए एक स्थिर शब्दकोश एक अच्छा तरीका हो सकता है।

ब्लॉकक्वाट 3. पारंपरिक ओओ पैटर्न शायद काम नहीं करेंगे।

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

+0

प्रश्न में ओओ भाषा पर निर्भर करता है। सी # कार्यात्मक तकनीकों के साथ एक बहुत अच्छा काम करता है। और कुछ चीजें जावा जैसी अधिक दर्दनाक अस्थिर ओओ भाषाओं में काफी कार्यात्मक तरीके से की जा सकती हैं, लेकिन निश्चित रूप से उस मामले में संज्ञानात्मक घर्षण की उचित मात्रा है। – JasonTrue

+1

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

+0

सी # कई कार्यात्मक तकनीकों पर फ्लैट गिरता है।बेहद सीमित प्रकार अनुमान केवल एक डीलरब्रेकर है। फ़ंक्शन के प्रकार को लिखने का प्रयास करें जो कई जेनेरिक पैरामीटर का उपयोग करता है, जैसे कार्यों का शब्दकोश। आउच। – MichaelGG

2

यदि आप गति की तलाश में हैं तो आप अंतर्निहित डेटा संरचनाओं पर विचार करना चाहेंगे। शब्दकोश <> सी # में एक हैश तालिका है जबकि SortedDictionary <> सी # में एक बाइनरी खोज पेड़ है।

एफ # और हास्केल दोनों पेड़ डेटा संरचनाओं का प्रतिनिधित्व करने का एक अच्छा काम करते हैं। आप डिफॉल्ट वाले सी # प्रदान करता है पर अधिक विशिष्ट डेटा संरचना का उपयोग करने पर विचार करना चाह सकते हैं।

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

+1

डनो सी # के बारे में, लेकिन एक उचित ढंग से लागू हैश तालिका में धीमी लुकअप नहीं है। लुकअप की गति को बनाए रखने के लिए, हालांकि, कभी-कभी सम्मिलन को पूरी तालिका को फिर से भरना पड़ता है। (लेकिन यह एक बड़ा सौदा नहीं है; यहां तक ​​कि बर्कलेडीबी भी ऑन-डिस्क हैश के लिए करता है।) हैश तालिका पर एक पेड़ का लाभ संदर्भ इलाका है; यदि आप "क्रम में" तालिका के एक हिस्से पर फिर से चल रहे हैं, तो "अगले" नोड्स को प्रीफ़ेच करना आसान है। – jrockway

+0

मैंने अपनी टिप्पणियों को तेज़ या धीमे के बारे में हटा दिया। हैश टेबल बनाम बाइनरी पेड़ के लिए कई अलग-अलग फायदे और नुकसान हैं जो आप उनका उपयोग करते हैं। सी # शब्दकोश <> वास्तव में एक तेज़ लुकअप समय है। "प्रोबिंग का उपयोग करके हैशटेबल जोड़ने, हटाने और खोजने के लिए औसत एसिम्प्टोटिक चलने का समय निरंतर समय है, ओ (1)" http://msdn.microsoft.com/en-us/library/ms379571(VS.80).aspx – gradbot

1

आप इसे उच्च स्तर पर कैसे डिजाइन करेंगे?

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

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

मैं सटीक समस्या को जानने के बिना और अधिक विशिष्टता नहीं दे सकता लेकिन आप आश्वस्त रह सकते हैं कि कई लोग इसे दैनिक आधार पर कर रहे हैं और यह बेहद अच्छी तरह से काम करता है।

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