कोड पुनरावृत्ति बनाम बहु जिम्मेदार विधि

Question

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

DoAction1();
DoAction2();

if (value)
    DoAction3();

DoAction4();

इस तरह के कोड को एक विधि में निकालने का सबसे अच्छा तरीका क्या है और इसे कैसे नाम दें?

Comments

वे एक अलग सार्थक विधि में निकालने के लिए प्रतिरोधी क्यों हैं?

— चंद्रवंशी

सभी क्रियाएं असंबंधित कुछ करती हैं। मैं लिखने के लिए होगा: void MethodThatDoAction1ThenAction2AndAction3IfValueAndThenAction4()। मैं नहीं बल्कि में अधिक अर्थ देखना होगा: CodeBlock1()।

— yBee

फिर यह केवल निकाली गई विधि को ठीक से नाम देने का सवाल है, है ना? मुझे डर है कि कोई सार्वभौमिक समाधान नहीं है और आपको केस के आधार पर ऐसा करना होगा। यदि आप 1 से अधिक स्थानों पर कोड के इस सटीक समान टुकड़े को दोहरा रहे हैं, तो आपके कार्यों के लिए एक अर्थ होने के लिए बाध्य है और आपको उस अर्थ को खोजने और इसे एक नाम देने के लिए कठिन (चर्चा की जा सकती है) देखने की आवश्यकता है।

— चंद्रवंशी

यदि यह कोई सांत्वना है, तो लंबे वर्ग के नामों के लिए स्प्रिंग विजेता AbstractInterruptibleBatchPreparedStatementSetterजो कि आपकी विधि से केवल एक छोटा है।

— चंद्रवंशी

@Chandranshu मुझे विश्वास है कि आपकी टिप्पणी इस सवाल के जवाब के रूप में ठीक काम करेगी।

— साइमन फोर्सबर्ग

Answer 1

मुझे लगता है कि यह केवल निकाले गए तरीके का नामकरण करने का सवाल है। मुझे डर है कि कोई सार्वभौमिक समाधान नहीं है और आपको केस के आधार पर ऐसा करना होगा। यदि आप 1 से अधिक स्थानों पर कोड के इस सटीक समान टुकड़े को दोहरा रहे हैं, तो आपके कार्यों के लिए एक अर्थ होने के लिए बाध्य है और आपको उस अर्थ को खोजने और इसे एक नाम देने के लिए कठिन (चर्चा की जा सकती है) देखने की आवश्यकता है।

यदि यह कोई सांत्वना है, तो लंबे वर्ग के नामों के लिए स्प्रिंग विजेता, AbstractInterruptibleBatchPreparedStatementSetterजो 49 वर्णों पर खड़ा है।

Answer 2

वास्तव में आप एक प्रोग्रामर - नेमिंग थिंग्स द्वारा करने के लिए सबसे कठिन कार्य से पीड़ित हैं । इस तरह के एक amature जवाब के लिए क्षमा करें, लेकिन मैं विरोध नहीं कर सका। आप पा सकते हैं कि बहुत से लोग इससे पीड़ित हैं , यहां तक ​​कि इंटरनेट में भी आप इस प्रकार का निबंध पा सकते हैं ।

अब यदि आपका दोहराव कोड सभी एक साथ है जिसके परिणामस्वरूप एक काम है और उन विधियों का उपयोग अन्य विधियों द्वारा नहीं किया जा रहा है तो वे बस हेल्पर्स विधि हैं और फिर परिणामी विधि को नाम दिया जा सकता है doXXXया makeXXX... मुझे लगता है कि आपको बिंदु मिल जाएगा।

जैसा कि चंद्रवंशु ने कहा है "यदि आप इसे दोहरा रहे हैं [...] अर्थ और इसे एक नाम दें।" बिंदु और उपयुक्त है।

Pic सौजन्य: CodeChef फेसबुक पेज फोटो

Answer 3

मुझे लगता है कि आप कोड पुनरावृत्ति सिद्धांत को बहुत दूर ले जा रहे हैं। कोड पुनरावृत्ति से बचने के बिंदु के बारे में सोचो। बिंदु कोड की मात्रा को कम करना है जिसे तर्क में बदलाव होने पर जांचना पड़ता है, और स्पष्ट रूप से समान रूप से ब्लॉक किए गए फैक्टरिंग द्वारा समझ बढ़ाने के लिए।

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

तो ध्यान से इस समानता के फैक्टरिंग द्वारा प्राप्त लाभ के खिलाफ दूसरों के बिना बदलते इन ब्लॉक में से एक के लिए तर्क की संभावना को ध्यान से तौलना । यदि एक कार्यान्वयन दूसरों से अलग हो सकता है तो आप कोड को दोहराते हुए बहुत बेहतर हो सकते हैं।

इस दोहराया कोड को बनाए रखने के दौरान, क्योंकि यह अधिक जटिल हो जाता है और आपका समस्या डोमेन अधिक परिभाषित हो जाता है, तो आप बार-बार, अब अधिक जटिल, लेकिन अधिक परिभाषित अनुभागों को भी कारक के लिए अधिक उपयुक्त पा सकते हैं।

मैं आमतौर पर टेक्स्ट-एडिटर को एक ही-नेस को कुछ समय के लिए बनाए रखने की कोशिश करता हूं, जब तक कि मैं यह नहीं देख सकता कि ऐसा कुछ जो दोहराए जाने वाले लगता है वह फैक्टरिंग के लायक है। मैं सिर्फ दोहराव रखता हूं, लेकिन मैं बाद में मिलान करने के लिए पाठ को आसान रखकर उस ब्लॉक के भविष्य की ओर अपनी नजर रखता हूं।

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

यह मुझे लगता है कि अगर लोग यह जानने की कोशिश करते हैं कि आप क्या करने की कोशिश कर रहे हैं, तो हमारे पास Do1Then2If2False Do1IfTrueDo2 जैसे बेकार निर्माणों की पूरी लाइब्रेरी होगी।

यह अधिक जटिल और अधिक स्पष्ट है कि ब्लॉक इसे बदलने वाले वारंट में बदलने वाला नहीं है।

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

Comments

मुझे वह भाग पसंद है जो कोड पुनरावृत्ति का सार निकालता है: तर्क में बदलाव होने पर कोड की मात्रा को कम करने के लिए जिसे

— जाँचना पड़ता है

Answer 4

यदि आप वास्तव में एकल जिम्मेदारी सिद्धांत का पालन कर रहे हैं, तो कोड के इस ब्लॉक में कुछ विशिष्ट उद्देश्य होना चाहिए, है ना? अन्यथा ये विधियाँ अलग-अलग वर्गों में होंगी।

तो फिर, इस कोड ब्लॉक का उद्देश्य क्या है? निर्धारित करें कि और आपको एक नाम के साथ आने में सक्षम होना चाहिए।

यदि आप अभी भी इस चीज़ के लिए नाम नहीं जान सकते हैं, तो हो सकता है कि ये विधियाँ वास्तव में एक साथ न हों। यानी इस वर्ग / कोड ब्लॉक में एक से अधिक जिम्मेदारी है। उस मामले में, कार्यों को विभाजित करने के लिए रिफैक्टिंग करने से बेहतर उद्देश्य-खुलासा नाम प्रकट हो सकता है।

Answer 5

मेरे पास एक स्थिति है जो आपके समान हो सकती है:

एक वर्ग है जो उस वस्तु की कार्यक्षमता को परिभाषित करता है जिसका वह प्रतिनिधित्व करता है:

class Functionality
{
protected:
void functionA();
void functionB();
...
void functionZ();
}

फिर एक ऐसा वर्ग होता है जो उच्च-स्तरीय संचालन के लिए वर्कफ़्लोज़ को परिभाषित करता है जो ऑब्जेक्ट करता है:

class Workflows: private Functionality
{
    void WorkflowA()
    {
        functionA();

        if (m_bValue) {
            functionB();
        }

        functionC();
    }
    ...
    void WorkflowB();
}

यदि आप एक समान स्थिति में हैं, तो पहचानें कि आपकी कक्षाएं क्या दर्शाती हैं (इस मामले में कार्यक्षमता / वर्कफ़्लोज़) और फिर उसी के अनुसार तरीकों को नाम दें।

डिस्क्लेमर: इस उदाहरण में उपयोग किए गए वर्ग के नाम मोटे तौर पर गलत हैं, लेकिन विधि के नाम एक सुराग देते हैं। विवेक ने सलाह दी।