एल्गोरिदम के डिजाइन और विश्लेषण के लिए कौन सा प्रतिमान बेहतर है? कौन सा तेज़ है? क्योंकि मेरे पास विश्वविद्यालय में एल्गोरिदम के डिजाइन और विश्लेषण नामक एक विषय है और कार्यक्रमों के लिए समय सीमा है। प्रक्रिया प्रोग्रामिंग से ओओपी धीमी है? या समय अंतर बड़ा नहीं है?एओजी बनाम पीपी एल्गोरिदम
आईएमओ एल्गोरिदम ओओ या पीपी मुद्दे से अलग हैं।
न तो ओओ या पीपी या तो डिजाइन-समय या प्रोग्राम प्रदर्शन में 'धीमी' हैं, वे अलग-अलग दृष्टिकोण हैं।
डिजाइन, विश्लेषण और विकास के लिए: निश्चित रूप से ओओपी। डिजाइनरों और डेवलपर्स के लाभ के लिए इसका आविष्कार किया गया था। प्रोग्राम रनटाइम निष्पादन के लिए: कभी-कभी पीपी अधिक कुशल होता है, लेकिन अक्सर ओओपी संकलक द्वारा सादे पीपी में कम हो जाता है, जिससे उन्हें बराबर बना दिया जाता है।
अंतर (निष्पादन समय में) सबसे अच्छा है।
ध्यान दें कि सरासर प्रदर्शन की तुलना में एक और महत्वपूर्ण कारक है: ओओपी प्रोग्रामर को अपने कोड को व्यवस्थित करने के बेहतर साधन प्रदान करता है जिसके परिणामस्वरूप अच्छी तरह से संरचित, समझने योग्य और अधिक विश्वसनीय (कम बग) प्रोग्राम होते हैं।
मुझे लगता है कि Functional Programming एल्गोरिदम के क्लीनर कार्यान्वयन का उत्पादन करेगा।
ऐसा कहकर, आपको जो भी दृष्टिकोण लेना है, उससे आपको बहुत अंतर नहीं दिखना चाहिए। एक एल्गोरिदम में भाषा या विकास प्रतिमान में व्यक्त किया जा सकता है।
अद्यतन: (निम्न टिप्पणी)
जाहिर कार्यात्मक प्रोग्रामिंग के साथ ही मैंने सोचा कि यह हो सकता है एल्गोरिदम को लागू करने के लिए खुद को उधार नहीं करता है। इसमें अन्य ताकतें हैं और मैंने ज्यादातर इसे पूर्णता के लिए उल्लेख किया है, क्योंकि प्रश्न केवल ओओपी (ऑब्जेक्ट उन्मुख प्रोग्रामिंग) और पीपी (प्रक्रियात्मक प्रोग्रामिंग) का उल्लेख करता है।
मेरा अनुमान है कि अंतर काफी बड़ा बारे में चिंता करने के बाद से एल्गोरिथ्म इस्तेमाल किया क्या महत्वपूर्ण है हो सकता है नहीं है, और समय सीमा के एक धीमी भाषा का प्रयोग अनुमति चाहिए, है। समय सीमा के प्रयोजन के IMO उदाहरण के लिए एक O (n) कलन विधि का उपयोग है जब वहाँ एक O (n n लॉग इन करें)
वस्तु उन्मुख प्रोग्रामिंग से कई निम्न स्तर विवरण abstracts से बचने के लिए आप प्राप्त करने के लिए किया जाना चाहिए प्रोग्रामर यह लक्ष्य
प्रक्रियात्मक प्रोग्रामिंग वस्तुओं, तरीकों, आभासी कार्यों आदि जैसे कई कपोल-कल्पना नहीं है
तो, गति के बारे में बात: एक अनुभवी विशेषज्ञ जो कि कैसे एक वस्तु उन्मुख प्रणाली एक लिख सकते हैं काम करेंगे के आंतरिक जानता है कार्यक्रम जो तेजी से चलता है।
कहा जा रहा है, गति लाभ OOP से अधिक उपयोग पीपी द्वारा हासिल की बहुत सीमांत हो जाएगा। यह नीचे से उबलता है कि आप आसानी से प्रोग्राम लिख सकते हैं।
संपादित करें:
एक दिलचस्प किस्सा मेरे मन की बात आती है: माइक्रोसॉफ्ट फाउंडेशन कक्षा में, संदेश और अन्य मैक्रोज़ BEGIN_MESSAGE_MAP की तरह दिखाई देता का उपयोग कर लागू किया गया था करने के लिए एक वस्तु से गुजर() END_MESSAGE_MAP(), और कारण यह था कि यह वर्चुअल फ़ंक्शंस का उपयोग करने से तेज़ था।
यह एक ऐसा मामला है जहां लाइब्रेरी डेवलपर्स ने ओओपी का उपयोग किया है, लेकिन जानबूझकर प्रदर्शन बाधा को दूर कर लिया है।
कमजोर लिंक आपके ज्ञान के रूप में है - कौन सी भाषा & प्रतिमान आप सबसे अधिक आरामदायक हैं।
ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग एल्गोरिदम के लिए विशेष रूप से प्रासंगिक नहीं है। प्रक्रियात्मक प्रोग्रामिंग की आपको आवश्यकता होगी, लेकिन जहां तक एल्गोरिदम का संबंध है, ऑब्जेक्ट उन्मुख प्रोग्रामिंग प्रक्रियात्मक प्रोग्रामिंग को पैकेज करने का एक और तरीका है। आपके पास रिकॉर्ड/structs के बजाय फ़ंक्शंस और कक्षाओं के बजाय विधियां हैं, लेकिन एकमात्र प्रासंगिक अंतर रन-टाइम प्रेषण है, और यह रन-टाइम निर्णय को संभालने का एक घोषणात्मक तरीका है जिसे किसी अन्य तरीके से संभाला जा सकता है।
ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग बड़े पैमाने पर - डिजाइन पैटर्न इत्यादि के लिए अधिक प्रासंगिक है - जबकि एल्गोरिदम छोटे पैमाने पर (आमतौर पर केवल एक) प्रक्रियाओं के छोटे पैमाने के लिए अधिक प्रासंगिक होते हैं।
बिल्कुल। ओओ कुछ और की तुलना में ऐप डिजाइन की संरचना के बारे में अधिक है। – kyoryu
लेखन कोड को आसान और कम त्रुटि प्रवण बनाने के लिए, आपको जेनरिक्स का समर्थन करने वाली भाषा की आवश्यकता है - जैसे कि जावा संग्रह फ्रेमवर्क के साथ एसटीएल या जावा के साथ सी ++। यदि आप किसी समय सीमा के विरुद्ध एल्गोरिदम लागू कर रहे हैं, तो आप अपने एल्गोरिदम को एक अच्छा ओ-ओ या जेनेरिक इंटरफ़ेस प्रदान करके समय बचाने में सक्षम हो सकते हैं, इसलिए कोड को स्वयं पूरी तरह से प्रक्रियात्मक बनाते हैं।
रन टाइम दक्षता के लिए, आप शायद प्रक्रियात्मक सी में सबकुछ लिख रहे होंगे - उदाहरण देखें "प्रोग्रामिंग का अभ्यास" में उदाहरण - लेकिन इसमें लिखने में काफी समय लगेगा, और आपको गलतियां करने की अधिक संभावना है। यह भी मानता है कि आपको आवश्यक सभी बिल्डिंग ब्लॉक प्रक्रियात्मक सी में भी सबसे अद्यतित और कुशल में उपलब्ध हैं, जो आजकल काफी धारणा है। एसटीएल या जेएफसी का उपयोग करने की संभावना अधिकतर आपको सीपीयू समय के साथ ही विकास के समय को बचाएगी।
कार्यात्मक भाषाओं के लिए, मुझे याद है कि कार्यात्मक प्रोग्रामिंग उत्साही सुनवाई करते हैं कि उनकी भाषा का उपयोग प्रतिस्पर्धा से कितना आसान है, और फिर यह देखते हुए कि कक्षा के उन सदस्यों ने जो कार्यात्मक भाषा चुनी थी, अभी भी संघर्ष कर रहे थे फोरट्रान 77 में समाप्त हो गया था और अपने कार्यक्रम के प्रदर्शन के ग्राफ तैयार करने के लिए चला गया था। मैं देखता हूं कि कार्यात्मक प्रोग्रामिंग समुदाय के दावों में बदलाव नहीं आया है। मुझे नहीं पता कि अंतर्निहित वास्तविकता क्या है।
सी का जिक्र करते समय मैं "लिखने के लिए अधिक समय लेना और गलतियों की अधिक संभावना" के बारे में पूरी तरह से असहमत हूं। यह उस बात पर निर्भर है कि हम किस बारे में बात कर रहे हैं। ओओपी कुछ उपयोगकर्ता लाभों के साथ बड़े उपयोगकर्ता ऐप्स लिखते समय कुछ शानदार लाभ देता है जहां डेटा/इनपुट गतिशील और अज्ञात (जेनेरिक का उपयोग) होता है। लेकिन वहां कई अन्य प्रणालियों के लिए, वेनिला सी में लेखन क्लीनर, आसान, तेज़ और कम त्रुटि प्रवण है। विशेष रूप से एम्बेडेड सिस्टम में। – Awaken
@Awaken - संदर्भ में मैं सहमत हूं। पेडेंटिक रूप से, हालांकि, सी का अधिकांश सी ++ निश्चित रूप से वैध है, इसलिए आप सी ++ लिख सकते हैं जैसे कि यह सी था, लेकिन जब भी इसकी आवश्यकता होती है तब भी वह अतिरिक्त टूल उपलब्ध होता है। सी ++ जावा नहीं है - आपको कक्षा में सब कुछ लपेटना नहीं है, आपको डिफ़ॉल्ट रूप से रन-टाइम प्रेषण नहीं मिलता है, आदि। – Steve314
@ एमसीडॉवेला - कुछ अच्छी ठोस अशुद्ध कार्यात्मक भाषाएं हैं।हास्केल "शुद्ध" और काफी अच्छा है, लेकिन मैं तर्क दूंगा कि हास्केल मोनैड के कारण अशुद्ध है - और विचार बहुत दिलचस्प है, लेकिन मैं मोनैडिक छद्म-अनिवार्य कोड को नापसंद करने आया हूं जिसका शुद्ध कार्य केवल अनुवाद किया गया है अनिवार्य स्रोत और अनिवार्य मशीन के बीच लीकी अबास्ट्रक्शन की दो परतों के साथ अनिवार्य रूप से अनुवाद किया गया। आईएमओ कार्यात्मक टूलकिट बेहद अच्छा है, लेकिन आपको अनिवार्य टूलकिट भी चाहिए। इसके अलावा, कार्यात्मक भाषाएं कुछ उपयोग करने में लगती हैं। परिचित कुंजी है। – Steve314
स्टीव 314 ने इसे अच्छी तरह से कहा। ओओपी बड़े अनुप्रयोगों के डिजाइन पैटर्न और संगठन के बारे में अधिक है। यह आपको अज्ञातों से बेहतर तरीके से निपटने देता है, जो उपयोगकर्ता ऐप्स के लिए बहुत अच्छा है। हालांकि, एल्गोरिदम का विश्लेषण करने के लिए, संभवतः आप जो करना चाहते हैं उसके बारे में सोचने के लिए जा रहे हैं। उस स्थिति में, जब आप एल्गोरिदम की परवाह करते हैं, तो मैं अधिक सरल पीपी से चिपक जाता हूं और पूरी तरह से ओओ डिज़ाइन बनाने की कोशिश नहीं करता हूं। मैं सी या मैटलैब के साथ काम करना चाहता हूं (इस बात पर निर्भर करता है कि गणित गहन गहन कैसे है)। बस इस पर मेरी राय।
मैंने एक बार Knuth-Morris-Pratt स्ट्रिंग खोज एल्गोरिदम अनुकूलित किया ताकि मेरे पास एक ऑब्जेक्ट हो जो एक समय में एक चरित्र ले ले और एक मैच/नो-मैच स्थिति वापस कर सके। यह एक सीधा-आगे अनुवाद नहीं था।
मैं असहमत हूं। एल्गोरिदम मूल रूप से * कैसे * आप कुछ करते हैं।कार्यात्मक प्रोग्रामिंग के बारे में मानक दावा यह है कि आप * क्या * चाहते हैं, * नहीं * यह कैसे करते हैं। विशेष रूप से, कई एल्गोरिदम के लिए इन-प्लेस अपडेट आवश्यक हैं। कार्यात्मक प्रोग्रामिंग के साथ, आप मूल रूप से * एल्गोरिदम की आवश्यकता * को आश्वस्त करते हैं और उम्मीद करते हैं कि संकलक/अनुकूलक निहितार्थ पर उठाता है। – Steve314
उदाहरण के लिए, सालों के लिए, संपूर्ण कार्यात्मक प्रोग्रामिंग समुदाय पूरी तरह से यह पता लगाने में असफल रहा कि एरेटोस्टेनेस (एक बहुत ही सरल और अच्छी तरह से समझी गई एल्गोरिदम) की चलनी का सामान्य कार्यात्मक कार्यान्वयन * बस * चाकू या एरेटोस्टेनेस बिल्कुल नहीं था और पूरी तरह से था गलत जटिलता। जब हजारों बुद्धिमान लोग यह पता लगाने में असफल होते हैं कि एक साधारण एल्गोरिदम ऐसा नहीं होता है, तो आप जानते हैं कि आपके पास एल्गोरिदम का वर्णन करने के लिए एक साफ या स्पष्ट तरीका नहीं है। – Steve314
दशकों से (वास्तव में, आज तक), संपूर्ण प्रक्रियात्मक प्रोग्रामिंग समुदाय पूरी तरह से यह निष्कर्ष निकालने में असफल रहा कि पूर्णांक अंकगणितीय (एक बहुत ही सरल और अच्छी तरह से समझा अंकगणित) का सामान्य प्रक्रियात्मक कार्यान्वयन केवल पूर्णांक गणित नहीं था और पूरी तरह से गलत था परिणाम है। जब लाखों बुद्धिमान लोग यह पता लगाने में असफल होते हैं कि एक साधारण अंकगणित ऐसा नहीं होता है, तो आप जानते हैं कि आपके पास अंकगणित का वर्णन करने के लिए एक साफ या स्पष्ट तरीका नहीं है। बीटीडब्लू: मैंने देखा है कि ज्यादातर स्विस गलत थे, चाहे वे कार्यात्मक, प्रक्रियात्मक, ओओ, तर्क, लागू किए गए थे ... –