यह सिर्फ एक सामान्य सहायता प्रश्न है, मैं यह जानने की कोशिश कर रहा हूं कि सी ++ एप्लिकेशन के कोड में छोटे कार्यों का एक सेट होने का क्या फायदा है, जिसमें एक समस्या को हल करने के लिए आवश्यक सभी कथन शामिल हैं?सी ++ में कई छोटे कार्यों में कोड को तोड़ने का क्या फायदा है?
संपादित क्रेडिट ओपी में टिप्पणीकर्ताओं को जाता है।
कई छोटे कार्यों में बड़े कार्यों को तोड़ने से मर्डर हो सकता है! जो, इस मामले में, एक अच्छी बात हो सकती है। :)
एम - अनुरक्षणीयता। छोटे, सरल कार्यों को बनाए रखना आसान है।
यू - समझदारी। सरल कार्यों को समझना आसान है।
आर - Reuseability। सामान्य संचालन को एक अलग समारोह में ले जाकर कोड पुन: उपयोग को प्रोत्साहित करता है।
डी - डीब्यूबिलिटी। जटिल लोगों की तुलना में सरल कार्यों को डीबग करना आसान है।
ई - एक्सटेंसिबिलिटी। कोड पुन: उपयोग और रखरखाव उन कार्यों को जन्म देता है जो 6 महीने में रिफैक्टर के लिए आसान होते हैं।
आर - रिग्रेशन। पुन: उपयोग और मॉड्यूलरलाइजेशन अधिक प्रभावी रिग्रेशन परीक्षण का कारण बनता है।
बड़ा कार्यों छोटे कार्यों के लिए में टूट के लिए कुछ संभावित लाभ कर रहे हैं। क्रम में वे मेरे दिमाग से बाहर गिर गए:
यह कोड-पुन: उपयोग को प्रोत्साहित करता है। अक्सर बड़े कार्यों में आपको कई बार एक ही चीज़ कम या कम करना पड़ता है। इसे एक सामान्य कार्य में सामान्यीकृत करके, आप एकाधिक स्थानों पर कोड के उस ब्लॉक का उपयोग कर सकते हैं।
कोड-पुन: उपयोग संभावित बग को कई जगहों के बजाय एक स्थान पर अलग करके मजबूती और रखरखाव में सहायता कर सकता है।
फ़ंक्शन के अर्थशास्त्र को समझना आसान है जब कोड की कम लाइनें हों और अच्छी तरह से नामित कार्यों के लिए कॉल का एक गुच्छा हो।
यदि आप एकाधिक रिटर्न पॉइंट्स के साथ फ़ंक्शंस का विरोध कर रहे हैं, तो बड़े कार्यों को तोड़ने से उन्हें कम करने में मदद मिल सकती है।
यह सूक्ष्म डेटा निर्भरताओं के साथ (संभावित) समस्याओं को पहचानने और अलग करने में मदद करता है जो अन्यथा ध्यान देने योग्य हैं।
यह ध्यान रखना महत्वपूर्ण है कि आप इसके साथ बुराई लेते हैं।
तो बड़ा समारोह से पहले काम किया, यह modularize को दोष बना सकते हैं की कोशिश कर रहा: वहाँ भी बड़ा कार्यों को तोड़ने के लिए कुछ संभावित कमियां हैं।
बहुप्रचारित अनुप्रयोगों में, यदि आप सिंक्रनाइज़ेशन नीतियां सूक्ष्म या केवल सादे गलत हैं तो आप डेडलॉक्स और रेस स्थितियों को पेश कर सकते हैं।
आप फ़ंक्शन कॉल से प्रदर्शन हिट पेश कर सकते हैं।
आपको बहुत बहुत धन्यवाद – Mody
स्पष्ट कोड जिसका अर्थ है समझना और बनाए रखना आसान है। इस स्मरक के लिए
धन्यवाद, बहुत सरल और स्पष्ट उत्तर – Mody
एक बड़ा जटिल कार्य केवल इतना है: जटिल।
अलग-अलग फ़ंक्शंस में आपके कोड को विभाजित करने से आपके कोड को काम करना बहुत आसान हो जाता है। सबसे पहले, जब आप किसी विशेष कार्य को करने वाले कोड के भाग की तलाश करते हैं, तो यह खोजना आसान होगा कि यह अपने कार्य में है या नहीं।
दूसरा, जब यह आसान होता है तो फ़ंक्शन में परिवर्तन करना बहुत आसान होता है - आपको उस फ़ंक्शन को संशोधित करने के लिए बड़ी मात्रा में कोड को समझने की आवश्यकता नहीं होती है।
इसके अलावा, आपको उस कोड को किसी अन्य प्रोजेक्ट में पुन: उपयोग करना आसान हो सकता है जब इसे छोटे कार्यों में विभाजित किया जाता है जो संभवतः एक बड़े कार्य के मुकाबले अधिक उद्देश्यों के लिए उपयोग किया जा सकता है।
कई कार्यों में एक कार्यक्रम को बंटवारे के लाभ हैं:
मेडिकल डिवाइस सिस्टम में, छोटे टुकड़ों में कोड तोड़ने से रिग्रेशन परीक्षण की आवश्यकता कम हो जाती है और परिवर्तन के प्रभाव को छोटे दायरे में बदल दिया जाता है।
उदाहरण के लिए, मान लीजिए कि हमारे पास एक फ़ाइल में 3 विषयों के लिए 15 कार्य हैं।
अगर मैं फ़ाइल में कार्यों में से एक बदलने के लिए, सब कुछ पुनर्निर्माण की जरूरत है और पुनर्परीक्षण।
यदि मैं फ़ाइल को 5 कार्यों की 3 अलग-अलग फ़ाइलों में विभाजित करता हूं, तो मुझे केवल 5 कार्यों को पुनर्निर्माण करने और 5 कार्यों को पुनर्निर्मित करने की आवश्यकता होती है। परीक्षण 5 कार्यों के लिए 15 कार्यों की तुलना में कम परीक्षण समय की आवश्यकता होती है।
साथ ही, जब लोग समान कोड आधार पर काम कर रहे हैं, तो कोड को विभाजित करने से एक ही फ़ाइल पर काम करने वाले दो या दो से अधिक लोगों की संभावना कम हो जाती है। एक ही फाइल पर काम करने वाले कई लोगों के पास कई संघर्ष होते हैं जैसे चेक-इन के दौरान एक व्यक्ति का कोड गलती से हटा दिया जाता है।
रखरखाव। Understandability। पुनर्प्रयोग। Debuggability। –
अधिक महत्वपूर्ण @KerrekSB एक्स्टेंसिबिलिटी –
मैं परीक्षण की आसानी भी जोड़ूंगा, जो मेरे अनुभव में पहले से नामित सभी अन्य लोगों को उत्पन्न करता है। – eh9