क्या विधि कॉल या स्वयं विधि की रक्षा करना बेहतर है?

Question

मैं एक आवेदन लिख रहा हूं और मुझे यह बात समझ आ गई है:

private void SomeMethod()
{
    if (Settings.GiveApples)
    {
        GiveApples();
    }

    if (Settings.GiveBananas)
    {
        GiveBananas();
    }
}

private void GiveApples()
{
    ...
}

private void GiveBananas()
{
    ...
}

यह बहुत सीधा-आगे दिखता है। कुछ शर्तें हैं और अगर वे सच हैं तो तरीकों को बुलाया जा रहा है। हालाँकि, मैं सोच रहा था, क्या ऐसा करना बेहतर है:

private void SomeMethod()
{
    GiveApples();
    GiveBananas();
}

private void GiveApples()
{
    if (!Settings.GiveApples)
    {
        return;
    }

    ...
}

private void GiveBananas()
{
    if (!Settings.GiveBananas)
    {
        return;
    }

    ...
}

दूसरे मामले में, प्रत्येक विधि खुद को गार्ड करती है, इसलिए भले ही उन तरीकों में से कोई भी GiveApplesया GiveBananasबाहर से बुलाया जाए SomeMethod, उन्हें केवल तभी निष्पादित किया जाएगा जब उनके पास सेटिंग्स में सही झंडा होगा।

क्या यह कुछ ऐसा है जिसे मुझे वास्तव में एक समस्या मानना ​​चाहिए?

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

Comments

यह इस बात पर निर्भर करता है कि आपको पहले चेक किए बिना कभी भी GiveApples या GiveBananas को कॉल करने की आवश्यकता हो सकती है। चूंकि गार्ड विधि के साथ जुड़ा हुआ है, यह संभवतः विधि में है।

— रॉबर्ट हार्वे

संबंधित (संभवतः एक डुप्लिकेट): गार्ड स्टेटमेंट्स और स्मॉल फ़ंक्शंस सह-अस्तित्व कैसे हो सकता है?

— १६:१६

Answer 1

मैं गार्ड के बारे में सोचता हूं क्योंकि कुछ विधि का पालन करना चाहिए। आपके उदाहरण में, विधि को Apple नहीं देना चाहिए यदि Settings.GiveApples गलत है।

अगर ऐसा है तो गार्ड निश्चित रूप से विधि के अंदर है। यह आपको पहले गार्ड की जांच के बिना अपने आवेदन में गलती से इसे दूसरे बिंदु से कॉल करने से रोकता है।

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

Answer 2

गार्ड को विधि के भीतर ही रखें। के उपभोक्ता GiveApples()या GiveBananas()के गार्ड प्रबंधन के लिए जिम्मेदार नहीं होना चाहिए GiveApples()।

एक डिजाइन के दृष्टिकोण से SomeMethod()केवल यह जानना चाहिए कि इसे फल की आवश्यकता है और इसे प्राप्त करने के लिए आपके आवेदन को क्या करना है, इसकी परवाह नहीं करनी चाहिए। यदि फलों की पुनर्प्राप्ति की अनुमति दी जाती है, तो SomeMethod()एक वैश्विक सेटिंग होती है जो यह जानने के लिए ज़िम्मेदार होती है कि फलों की पुनर्प्राप्ति का अमूर्त रिसाव हो जाता है । अगर आपका गार्ड तंत्र कभी बदल जाता है, तो यह कैस्केड हो जाता है, क्योंकि अब इस नए गार्ड को लागू करने के लिए सभी तरीकों को अलग-अलग करने GetApples()या GetBananas()अलग करने की आवश्यकता है। जब आप कोड लिख रहे हों, तो उस जांच को भूलकर फल प्राप्त करना बहुत आसान है।

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

Answer 3

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

private void SomeMethod()
{
    GiveApplesIfActivated();
    GiveBananasIfActivated();
}

private void GiveApplesIfActivated()
{
    if (Settings.GiveApples)
    {
        GiveApples();
    }
}

private void GiveBananasIfActivated()
{
    if (Settings.GiveBananas)
    {
        GiveBananas();
    }
}

private void GiveApples()
{
    ...
}

private void GiveBananas()
{
    ...
}

यह आपको कक्षा से किसी भी निर्भरता के बिना GiveApplesऔर / या GiveBananasएक अलग जगह में कोड को फिर से भरने का बेहतर मौका देता है Settings। यह स्पष्ट रूप से फायदेमंद है जब आप एक यूनिट टेस्ट में उन तरीकों को कॉल करना चाहते हैं जो किसी की परवाह नहीं करते हैं Settings।

हालाँकि, अगर यह आपके प्रोग्राम में हमेशा गलत है, किसी भी परिस्थिति में, यहां तक ​​कि परीक्षण के संदर्भ में, GiveApplesकिसी संदर्भ के बाहर की तरह कुछ को कॉल करने के लिए, जहां Settings.GiveApplesपहले जाँच की जाती है, और आप इंप्रेशन के GiveApplesबिना Settingsचेक की तरह एक फ़ंक्शन प्रदान कर रहे हैं , त्रुटि-प्रवण है , फिर उस संस्करण से चिपके रहें जहाँ आप Settings.GiveApplesअंदर परीक्षण करते हैं GiveApples।