"एक विधि का मूल मान वापस लौटना चाहिए या उसके दुष्प्रभाव होने चाहिए, लेकिन दोनों नहीं"

Question

मैं एक बार पढ़ता हूं कि एक विधि में या तो रिटर्न वैल्यू होनी चाहिए (और संदर्भित रूप से पारदर्शी होनी चाहिए), या साइड-इफेक्ट (एस) हो, लेकिन दोनों। मुझे इस नियम का कोई संदर्भ नहीं मिल रहा है, लेकिन मैं इसके बारे में और जानना चाहता हूं।

इस सलाह का मूल क्या है? किस व्यक्ति या समुदाय से यह उत्पन्न हुआ?

अतिरिक्त क्रेडिट: इस सलाह का पालन करने का दावा किया लाभ क्या है?

Comments

@gnat हां, यह मुख्य रूप से इतिहास के बारे में है। मुझे डर था कि अतिरिक्त क्रेडिट हिस्सा अपने आप ही खड़ा होने के लिए बहुत व्यक्तिपरक था, और यह इतिहास बंद होने से बचने का एक बेहतर मौका था। मैं टैग जोड़ दूंगा।

— वेन कॉनराड

उन उत्तरों में से कुछ जो मुझे आश्चर्यचकित करते हैं कि क्या आप उस लाभ के बारे में पूछते हैं जो इस सलाह के लेखक द्वारा दावा किया गया था या उन सभी लाभों की सूची के लिए जो दावा करना संभव है?

— ग्नत १६'१५ को

@gnat मैं लेखक द्वारा दावा किए गए लाभ के बारे में पूछता हूं (फिर से, बंद होने का डर है), लेकिन मुझे यकीन है कि ढेर के कारणों पर कोई आपत्ति नहीं है - वे उस सवाल का जवाब दे रहे हैं जो मैं वास्तव में पूछना चाहता था । अगर मैं अपने प्रश्न से "दावा" हटा देता, तो पाइल-ऑन उत्तरों को विषय बना देता, तो क्या यह प्रश्न व्यक्तिपरक में बहुत दूर होता?

— वेन कॉनराड

"ढेर-ऑन कारण" सवाल को बहुत व्यापक के रूप में बंद करने की संभावना है । यदि आप इसे "खुले किनारे पर रहने के लिए" पसंद करते हैं, तो मुझे लगता है कि लेखक द्वारा दावा किया गया लाभ के लिए इसे संकीर्ण करना अधिक सुरक्षित होगा

— gnat

एक लाभ यह है कि यदि आपको कोड की मात्रा द्वारा भुगतान किया जाता है, तो यह अतिरिक्त उत्पादन करता है। "doSomething; GetResultOfSomething; हैंडलेयर्सफ्रेमसंरोमिंग;"

— Ⴖ uі

Answer 1

ग्रेग यंग के अनुसार, यह विचार बर्ट्रेंड मेयर : कमांड-क्वेरी अलगाव से उत्पन्न हुआ था ।

यह बताता है कि हर विधि या तो एक कमांड होनी चाहिए जो एक क्रिया करती है, या एक क्वेरी जो कॉल करने वाले को डेटा लौटाती है, लेकिन दोनों नहीं। दूसरे शब्दों में, एक प्रश्न पूछने से उत्तर नहीं बदलना चाहिए । ¹ अधिक औपचारिक रूप से, विधियों को केवल तभी मूल्य वापस करना चाहिए जब वे संदर्भित रूप से पारदर्शी हों और इसलिए कोई साइड इफेक्ट न हो।

1: एफिल: सॉफ्टवेयर इंजीनियरिंग स्लाइड 43-48 के लिए एक भाषा

डोमेन ड्रिवेन डिज़ाइन में, यह ग्रेग यंग द्वारा नामित कमांड-क्वेरी-रीड सेपरेशन / सेग्रीगेशन (CQRS) के समान है।

ग्रेग यंग ने CQRS के लेख में मार्टिन फाउलर द्वारा बताए गए CQRS का नाम बर्ट्रेंड से लिया।

लाभ

• रीड (क्वेरी) भाग को राइट (कमांड) भाग से अलग / छोटा किया जा सकता है। अनुकूलन / प्रदर्शन प्रमुख होने पर दोनों को अलग करने से या तो एक दूसरे के रास्ते में आने से रोका जा सकेगा।

अधिक के लिए मार्टिन फॉलर लिंक में लेख पढ़ें ।

Comments

स्वाभाविक रूप से, कई परिस्थितियों में एक उपयोगी परिणाम उत्पन्न करना और एक ही समय में कुछ संशोधन करना दोनों को अलग से कठिन करने से अधिक महंगा नहीं है।

— डेडुप्लिकेटर

@Deduplicator एक क्लीच उदाहरण है इंटरलॉक्ड कॉमप्लेएक्सचेंज?

— Ⴖ uі

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

— टी। सर

Answer 2

मुझे नहीं पता कि यह कहाँ से आता है, लेकिन यह अच्छी सलाह है और समझने के लिए काफी सीधा-सीधा है।

किसी भी डिज़ाइन किए गए कार्यक्रम को विभिन्न भागों में विभाजित किया जाएगा, संयुक्त और विभिन्न तरीकों से बनाया जाएगा। किसी विशेष भाग के लिए यह करना जितना कठिन होता है, उतना ही कठिन यह सुनिश्चित करना होगा कि आपका कार्यक्रम अनुमानित रूप से प्रतिक्रिया देगा।

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

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

Comments

यह पूछे गए प्रश्न को संबोधित करने का प्रयास भी नहीं करता है, देखें कि उत्तर कैसे दें

— gnat

@gnat मेरा प्रश्न दो भागों में आया: मुख्य प्रश्न ("कौन"), और अतिरिक्त क्रेडिट ("क्यों)। क्या यह अतिरिक्त क्रेडिट भाग को संबोधित नहीं करता?

— वेन कॉनराड

मेरे पढ़ने के अनुसार (" दावा किया गया लाभ"), उद्धरण के लेखक द्वारा प्रस्तावित एक-भाग क्यों अपेक्षित है। प्रश्न सभी संभावित लाभों की सूची के लिए पूछते नहीं दिखाई देते हैं

— gnat

@ जिनात ने इस सलाह को समझने की कोशिश के रूप में प्रश्न को समझा, इसके पीछे का कारण और साथ ही साथ यह संदर्भ भी दिया। मैं नहीं मानता कि प्रश्न के केवल भाग को संबोधित करना अनुचित था।

— मॉर्गन

Answer 3

अतिरिक्त क्रेडिट: इस सलाह का पालन करने का मूल रूप से दावा किया गया लाभ क्या है ?

साइड इफेक्ट्स से वापसी मूल्य को अलग करने का एक लाभ यह है कि यह एक संभावित समस्या को दूर करता है जो शॉर्ट-सर्किट मूल्यांकन के कारण हो सकता है ।

bool FooWithSideEffect() {
    // do query
    // do side effect
    return resultOfQuery;
}

bool BarWithSideEffect() {
    // do query
    // do side effect
    return resultOfQuery;
}

void BadShortCircuitEvaluation()
{
    // the programmer's intent is to have side effects of both functions
    if (FooWithSideEffect() && BarWithSideEffect() ) {
        // do something
    }

    // in case FooWithSideEffect() returns true, 
    // then BarWithSideEffect() is not called at all
    // because of short-circuit evaluation
}

Comments

क्या यह सलाह के लेखक द्वारा दावा किया गया लाभ है ?

— gnat

@ जगत् ने मुझे ऐतिहासिक और व्यावहारिक मिलाया है, मुझे डर है।

— निक अलेक्सिएव

टिप्पणी और कोड मेल नहीं खाते, BarWithSideEffects नहीं कहा जाता है अगर FooWithSideEffects गलत

— jk देता है।