क्या एक बड़ी बूलियन अभिव्यक्ति एक ही अभिव्यक्ति की तुलना में विधेय विधियों में टूट गई है? [बन्द है]

Question

समझने में आसान क्या है, एक बड़ा बूलियन स्टेटमेंट (काफी जटिल), या एक ही बयान प्रेडिकेट विधियों (पढ़ने के लिए बहुत सारे अतिरिक्त कोड) में टूट गया?

विकल्प 1, बड़ी बूलियन अभिव्यक्ति:

    private static bool ContextMatchesProp(CurrentSearchContext context, TValToMatch propVal)
    {

        return propVal.PropertyId == context.Definition.Id
            && !repo.ParentId.HasValue || repo.ParentId == propVal.ParentId
            && ((propVal.SecondaryFilter.HasValue && context.SecondaryFilter.HasValue && propVal.SecondaryFilter.Value == context.SecondaryFilter) || (!context.SecondaryFilter.HasValue && !propVal.SecondaryFilter.HasValue));
    }

विकल्प 2, स्थितियाँ विधेय विधियों में टूट गई:

    private static bool ContextMatchesProp(CurrentSearchContext context, TValToMatch propVal)
    {
        return MatchesDefinitionId(context, propVal)
            && MatchesParentId(propVal)
            && (MatchedSecondaryFilter(context, propVal) || HasNoSecondaryFilter(context, propVal));
    }

    private static bool HasNoSecondaryFilter(CurrentSearchContext context, TValToMatch propVal)
    {
        return (!context.No.HasValue && !propVal.SecondaryFilter.HasValue);
    }

    private static bool MatchedSecondaryFilter(CurrentSearchContext context, TValToMatch propVal)
    {
        return (propVal.SecondaryFilter.HasValue && context.No.HasValue && propVal.SecondaryFilter.Value == context.No);
    }

    private bool MatchesParentId(TValToMatch propVal)
    {
        return (!repo.ParentId.HasValue || repo.ParentId == propVal.ParentId);
    }

    private static bool MatchesDefinitionId(CurrentSearchContext context, TValToMatch propVal)
    {
        return propVal.PropertyId == context.Definition.Id;
    }

मैं दूसरे दृष्टिकोण को पसंद करता हूं, क्योंकि मैं विधि के नाम को टिप्पणियों के रूप में देखता हूं, लेकिन मैं समझता हूं कि यह समस्याग्रस्त है क्योंकि आपको यह समझने के लिए सभी तरीकों को पढ़ना होगा कि कोड क्या करता है, इसलिए यह कोड के इरादे को सार करता है।

Comments

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

— प्रोग्रामर

क्या यह वास्तव में एक ही अभिव्यक्ति है? "या" की तुलना में कम पूर्वता है "और", वैसे भी दूसरा आपके इरादे को बताता है, दूसरा (पहला) तकनीकी है।

— द पैकर

@Thepacker क्या कहता है। तथ्य यह है कि यह पहला तरीका है कि आप एक गलती करने के लिए कारण बना है एक बहुत अच्छा सुराग है कि पहला तरीका आसानी से अपने लक्षित दर्शकों के एक बहुत ही महत्वपूर्ण क्षेत्र के लिए समझ में नहीं आता है। स्वयं!

— स्टीव जेसप

विकल्प 3: मुझे एक भी पसंद नहीं है। दूसरा हास्यास्पद रूप से क्रिया है, पहला दूसरे के बराबर नहीं है। कोष्ठक मदद करते हैं।

— डेविड हैमेन 15

यह पांडित्य हो सकता है, लेकिन आपके पास कोड के किसी भी ब्लॉक में कोई if बयान नहीं है । आपका प्रश्न बूलियन अभिव्यक्तियों के बारे में है ।

— काइल स्ट्रैंड

Answer 1

समझने में आसान क्या है

बाद का दृष्टिकोण। यह न केवल समझना आसान है, बल्कि लिखना, परीक्षण, रिफ्लेक्टर और विस्तार करना भी आसान है। प्रत्येक आवश्यक स्थिति को सुरक्षित रूप से डिकोड किया जा सकता है और इसे अपने तरीके से नियंत्रित किया जा सकता है।

यह समस्याग्रस्त है क्योंकि आपको कोड को समझने के लिए सभी तरीकों को पढ़ना होगा

यदि विधियों का ठीक से नाम लिया जाए तो यह समस्याग्रस्त नहीं है। वास्तव में यह समझना आसान होगा क्योंकि विधि का नाम स्थिति की मंशा का वर्णन करेगा।
एक दर्शक के if MatchesDefinitionId()लिए की तुलना में अधिक व्याख्यात्मक हैif (propVal.PropertyId == context.Definition.Id)

[व्यक्तिगत रूप से, पहला दृष्टिकोण मेरी आँखों को खोखला कर देता है।]

Comments

यदि विधियों के नाम अच्छे हैं, तो समझना भी आसान है।

— B39овиЈ

और कृपया, उन्हें (विधि नाम) महत्वपूर्ण और संक्षिप्त बनाएं। 20+ वर्ण विधि के नाम ने मेरी आँखों को छलनी कर दिया। MatchesDefinitionId()सीमा रेखा है।

— १२:१२ पर माइंडविन

@ मिन्डविन अगर यह विधि के नाम "संक्षिप्त" रखने और उन्हें सार्थक रखने के बीच एक विकल्प पर आता है, तो मैं कहता हूं कि हर बार बाद में ले लो। शॉर्ट अच्छा है, लेकिन पठनीयता की कीमत पर नहीं।

— Ajedi32

@ Ajedi32 विधि नाम पर विधि क्या करता है, या व्याकरणिक रूप से ध्वनि विधि के नाम पर निबंध लिखने की जरूरत नहीं है। यदि कोई संक्षिप्त नाम मानकों को स्पष्ट रखता है (कार्य समूह या संगठन में) तो संक्षिप्त नाम और पठनीयता की समस्या नहीं होगी।

— माइंडविन

जिपफ के नियम का उपयोग करें: चीजों को उनके उपयोग को हतोत्साहित करने के लिए और अधिक क्रिया करें।

— 15os में 15

Answer 2

यदि यह एकमात्र स्थान है जहाँ इन विधेय कार्यों का उपयोग किया जाएगा, तो आप boolइसके स्थान पर स्थानीय चर का उपयोग भी कर सकते हैं :

private static bool ContextMatchesProp(CurrentSearchContext context, TValToMatch propVal)
{
    bool matchesDefinitionId = (propVal.PropertyId == context.Definition.Id);
    bool matchesParentId = (!repo.ParentId.HasValue || repo.ParentId == propVal.ParentId);
    bool matchesSecondaryFilter = (propVal.SecondaryFilter.HasValue && context.No.HasValue && propVal.SecondaryFilter.Value == context.No);
    bool hasNoSecondaryFilter = (!context.No.HasValue && !propVal.SecondaryFilter.HasValue);

    return matchesDefinitionId
        && matchesParentId
        && matchesSecondaryFilter || hasNoSecondaryFilter;
}

इन्हें और भी तोड़ा जा सकता है और इन्हें अधिक पठनीय बनाने के लिए पुन: व्यवस्थित किया जाता है, जैसे कि

bool hasSecondaryFilter = propVal.SecondaryFilter.HasValue;

और फिर के सभी उदाहरणों की जगह propVal.SecondaryFilter.HasValue। एक चीज जो तुरंत चिपक जाती है, वह यह है कि hasNoSecondaryFilterतार्किक और नकारात्मक HasValueगुणों matchesSecondaryFilterका उपयोग करता है , जबकि एक तार्किक और गैर-नकारात्मक का उपयोग करता है HasValue- इसलिए यह बिल्कुल विपरीत नहीं है।

Comments

यह समाधान बहुत अच्छा है और मैंने निश्चित रूप से समान कोड के बहुत सारे लिखा है। यह बहुत पठनीय है। मेरे द्वारा पोस्ट किए गए समाधान की तुलना में नकारात्मक पक्ष, गति है। इस पद्धति के साथ, आप सशर्त परीक्षणों के ढेर पर कोई फर्क नहीं पड़ता कि क्या करते हैं। मेरे समाधान में, संसाधित किए गए मूल्यों के आधार पर ऑपरेशन को नाटकीय रूप से कम किया जा सकता है।

— १

@ BuvinJ टेस्ट यहां दिखाए गए लोगों की तरह ही काफी सस्ते होने चाहिए, इसलिए जब तक मुझे पता है कि कुछ शर्तें महंगी हैं या जब तक यह अत्यंत प्रदर्शन संवेदनशील कोड नहीं है, मैं अधिक पठनीय संस्करण के लिए जाऊंगा।

— 17

@svick इसमें कोई संदेह नहीं है कि अधिकांश समय प्रदर्शन के मुद्दे को पेश करने की संभावना नहीं है। फिर भी, यदि आप पठनीयता खोए बिना संचालन को कम कर सकते हैं, तो ऐसा क्यों नहीं करें? मुझे यकीन नहीं है कि यह मेरे समाधान से बहुत अधिक पठनीय है। यह परीक्षणों के लिए स्व-दस्तावेजीकरण "नाम" देता है - जो अच्छा है ... मुझे लगता है कि यह विशिष्ट उपयोग के मामले में नीचे आता है और परीक्षण अपने आप में कितना समझ में आता है।

— BuvinJ

टिप्पणियों को जोड़ने से पठनीयता में भी मदद मिल सकती है ...

— BuvinJ

@BuvinJ मुझे इस समाधान के बारे में वास्तव में क्या पसंद है कि अंतिम पंक्ति को छोड़कर सब कुछ अनदेखा करके, मैं जल्दी से समझ सकता हूं कि यह क्या कर रहा है। मुझे लगता है कि यह अधिक पठनीय है।

— sv

Answer 3

सामान्य तौर पर, बाद वाले को पसंद किया जाता है।

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

ओह, और यह इस चीज़ को इकाई परीक्षण के लिए बहुत आसान बनाता है, आपको यह विश्वास दिलाता है कि आपने इसे सही तरीके से किया है।

Comments

हां, यद्यपि आपके उत्तर में भी repoस्थैतिक क्षेत्र / संपत्ति, यानी एक वैश्विक परिवर्तनशील का उपयोग करते हुए पते को ठीक करना चाहिए । स्टैटिक्स विधियाँ नियतात्मक होनी चाहिए और वैश्विक चर का उपयोग नहीं करना चाहिए।

— डेविड अरनो

@ दाविदराव - जबकि यह महान नहीं है, यह हाथ में प्रश्न के लिए स्पर्शरेखा लगता है। और अधिक कोड के बिना यह प्रशंसनीय है कि डिजाइन की तरह काम करने के लिए एक अर्ध-वैध कारण है।

— तेलस्टिन

हां, रेपो कभी नहीं। मुझे कोड को थोड़ा बाधित करना पड़ा, ग्राहक कोड को साझा नहीं करना चाहता, जैसा कि इंटरवेब पर है :)

— willem

Answer 4

यदि यह इन दो विकल्पों के बीच है, तो बाद वाला बेहतर है। हालांकि ये एकमात्र विकल्प नहीं हैं! कैसे कई ifs में एकल समारोह को तोड़ने के बारे में? अतिरिक्त परीक्षणों से बचने के लिए फ़ंक्शन से बाहर निकलने के तरीकों के लिए परीक्षण, मोटे तौर पर एक एकल लाइन परीक्षण में "शॉर्ट सर्किट" का अनुकरण करना।

यह पढ़ना आसान है (आपको अपने उदाहरण के लिए तर्क की दोहरी जांच करने की आवश्यकता हो सकती है, लेकिन अवधारणा सही है):

private static bool ContextMatchesProp(CurrentSearchContext context, TValToMatch propVal)
{
    if( propVal.PropertyId != context.Definition.Id ) return false;

    if( repo.ParentId.HasValue || repo.ParentId != propVal.ParentId ) return false;

    if( propVal.SecondaryFilter.HasValue && 
        context.SecondaryFilter.HasValue && 
        propVal.SecondaryFilter.Value == context.SecondaryFilter ) return true;

    if( !context.SecondaryFilter.HasValue && 
        !propVal.SecondaryFilter.HasValue) return true;

    return false;   
}

Comments

इसे पोस्ट करने के कुछ सेकंड के भीतर मुझे इसके लिए एक डाउनवोट क्यों मिला? कृपया एक टिप्पणी जोड़ें जब आप नीचे जाएँ! यह उत्तर बस जल्दी से संचालित होता है और पढ़ने में आसान होता है। तो समस्या क्या है?

— BuvinJ

@ बुविज: बिल्कुल इसके साथ कुछ भी गलत नहीं है। मूल कोड के समान, सिवाय आपको एक दर्जन कोष्ठक और एक पंक्ति के साथ नहीं लड़ना पड़ता है जो स्क्रीन के अंत में फैला होता है। मैं उस कोड को ऊपर से नीचे तक पढ़ सकता हूं और तुरंत समझ सकता हूं। डब्ल्यूटीएफ काउंट = 0.

— gnasher729

फ़ंक्शन के अंत के अलावा अन्य रिटर्निंग कोड को कम पठनीय बनाता है, अधिक पठनीय नहीं, आईएमओ। मैं सिंगल एक्जिट पॉइंट पसंद करता हूं। इस लिंक पर कुछ अच्छे तर्क दिए गए हैं। stackoverflow.com/questions/36707/…

— ब्रैड थॉमस

@ ब्रैड थोमस मैं एकल निकास बिंदु से सहमत नहीं हो सकता। यह आमतौर पर गहरी नेस्टेड कोष्ठक की ओर जाता है। मेरे लिए वापसी बहुत आसान है।

— बोरजब

@BradThomas मैं पूरी तरह से Borjab से सहमत हूँ। गहरी घोंसले से बचना वास्तव में यही कारण है कि मैं लंबे सशर्त बयानों को तोड़ने के बजाय इस शैली का अधिक बार उपयोग करता हूं। मैं खुद को घोंसले के टन के साथ कोड लिखने के लिए उपयोग करता हूं। फिर, मैंने उन तरीकों की तलाश शुरू कर दी, जो शायद ही कभी एक या दो घोंसले से अधिक गहरे तक जाते हों, और परिणामस्वरूप मेरा कोड पढ़ना और बनाए रखना आसान हो गया है। यदि आप अपने कार्य से बाहर निकलने का एक रास्ता खोज सकते हैं, तो जितनी जल्दी हो सके ऐसा करें! यदि आप गहरी घोंसले और लंबी स्थिति से बचने का एक तरीका खोज सकते हैं, तो ऐसा करें!

— १

Answer 5

मुझे विकल्प 2 बेहतर लगता है, लेकिन यह एक संरचनात्मक परिवर्तन का सुझाव देगा। सशर्त की अंतिम पंक्ति पर दो चेक को एक कॉल में मिलाएं।

private static bool ContextMatchesProp(CurrentSearchContext context, TValToMatch propVal)
{
    return MatchesDefinitionId(context, propVal)
        && MatchesParentId(propVal)
        && MatchesSecondaryFilterIfPresent(context, propVal);
}

private static bool MatchesSecondaryFilterIfPresent(CurrentSearchContext context, 
                                                    TValToMatch propVal)
{
    return MatchedSecondaryFilter(context, propVal) 
               || HasNoSecondaryFilter(context, propVal);
}

इसका कारण यह है कि मैं यह बताता हूं कि दो चेक एक एकल कार्यात्मक इकाई हैं, और एक सशर्त में कोष्ठक को घोंसले में डालने की त्रुटि है: दोनों शुरू में कोड लिखने के दृष्टिकोण से और इसे पढ़ने वाले व्यक्ति के दृष्टिकोण से। यह विशेष रूप से मामला है अगर अभिव्यक्ति के उप-तत्व समान पैटर्न का पालन नहीं करते हैं।

मुझे यकीन नहीं है कि अगर MatchesSecondaryFilterIfPresent()संयोजन के लिए सबसे अच्छा नाम है; लेकिन बेहतर कुछ भी तुरंत दिमाग में नहीं आ रहा है।

Comments

बहुत अच्छा, यह समझाने की कोशिश करना कि विधियों के अंदर क्या किया जा रहा है, वास्तव में सिर्फ पुनर्गठन कॉल से बेहतर है।

— कलार

Answer 6

हालांकि C # में, कोड बहुत ऑब्जेक्ट ओरिएंटेड नहीं है। यह स्थैतिक तरीकों का उपयोग कर रहा है और स्थिर क्षेत्रों (जैसे repo) की तरह दिखता है । यह आमतौर पर माना जाता है कि स्टैटिक्स आपके कोड को रिफ्लेक्टर के लिए कठिन और परीक्षण के लिए कठिन बनाते हैं, जबकि पुन: प्रयोज्य में बाधा, और, आपके प्रश्न के लिए: वस्तु-आधारित निर्माण की तुलना में इस तरह स्थिर उपयोग कम पठनीय और बनाए रखने योग्य है।

आपको इस कोड को अधिक ऑब्जेक्ट-ओरिएंटेड फ़ॉर्म में बदलना चाहिए। जब आप करते हैं, तो आप पाएंगे कि कोड डालने के लिए समझदार स्थान हैं जो वस्तुओं की तुलना करता है, खेतों की, आदि। यह संभावना है कि आप तब वस्तुओं की तुलना खुद से करने के लिए कह सकते हैं, जो आपके बड़े को कम कर देगा यदि एक बयान में तुलना करने के लिए सरल अनुरोध (उदाहरण के लिए if ( a.compareTo (b) ) { }, जिसमें सभी फ़ील्ड तुलना शामिल हो सकते हैं।)

C # में वस्तुओं और उनके क्षेत्रों पर तुलना करने के लिए इंटरफेस और सिस्टम उपयोगिताओं का एक समृद्ध सेट है। स्पष्ट परे .Equalsविधि, शुरुआत के लिए, इस पर गौर IEqualityComparer, IEquatable, और उपयोगिताओं की तरह System.Collections.Generic.EqualityComparer.Default।

Answer 7

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

Answer 8

मैं कहूंगा कि दोनों एक ही हैं, यदि आप पठनीयता के लिए कुछ व्हाट्सएप जोड़ते हैं और अधिक अस्पष्ट भागों पर पाठक की मदद करने के लिए कुछ टिप्पणियां करते हैं।

याद रखें: अच्छी टिप्पणी पाठक को बताती है कि आप कोड लिखते समय क्या सोच रहे थे ।

मेरे द्वारा सुझाए गए परिवर्तनों के साथ, मैं शायद पूर्व दृष्टिकोण के साथ जाऊंगा, क्योंकि यह कम अव्यवस्थित और फैलाना है। सबरूटीन कॉल फुटनोट की तरह होते हैं: वे उपयोगी जानकारी प्रदान करते हैं लेकिन पढ़ने के प्रवाह को बाधित करते हैं। यदि विधेय अधिक जटिल थे, तो मैं उन्हें अलग-अलग तरीकों से तोड़ दूंगा ताकि वे जिन अवधारणाओं को अपनाते हैं, उन्हें समझने योग्य विखंडों में बनाया जा सके।

Comments

एक +1 का वर्णन करता है। विचार के लिए अच्छा भोजन, भले ही अन्य उत्तरों के आधार पर लोकप्रिय राय न हो। धन्यवाद :)

— विलेम

@willem नहीं, यह +1 के लायक नहीं है। दो दृष्टिकोण समान नहीं हैं। अतिरिक्त टिप्पणियां मूर्खतापूर्ण और अनावश्यक हैं।

— B45овиЈ

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

— वंडरबेल

कमेंट को फॉलो करने से बेहतर है कि उसका नाम सार्थक हो। जैसा कि "क्लीन कोड" पुस्तक में कहा गया है कि एक टिप्पणी फेंक कोड को व्यक्त करने में विफलता है। क्यों समझाएँ कि आप क्या कर रहे हैं जब फ़ंक्शन इसे और अधिक स्पष्ट रूप से बता सकता था।

— बोरबज़

Answer 9

ठीक है, अगर कुछ ऐसे भाग हैं जिनका आप पुनः उपयोग करना चाहते हैं, तो उन्हें अलग-अलग ठीक से नामित कार्यों में अलग करना स्पष्ट रूप से सबसे अच्छा विचार है।
यहां तक ​​कि अगर आप उन्हें कभी भी पुन: उपयोग नहीं कर सकते हैं, तो ऐसा करने से आप अपनी स्थितियों को बेहतर ढंग से तैयार कर सकते हैं और उन्हें एक लेबल दे सकते हैं जिसमें उनका मतलब होता है ।

अब, अपने पहले विकल्प पर नजर डालते हैं, और स्वीकार करते हैं कि न तो आपका इंडेंटेशन था और न ही यह सब उपयोगी था और न ही सशर्त सभी को अच्छी तरह से संरचित किया गया था:

private static bool ContextMatchesProp(CurrentSearchContext context, TValToMatch propVal) {
    return propVal.PropertyId == context.Definition.Id && !repo.ParentId.HasValue
        || repo.ParentId == propVal.ParentId
        && propVal.SecondaryFilter.HasValue == context.SecondaryFilter.HasValue
        && (!propVal.SecondaryFilter.HasValue || propVal.SecondaryFilter.Value == context.SecondaryFilter.Value);
}

Answer 10

पहला वाला बिल्कुल भयानक है। आप उपयोग कर रहे हैं || एक ही लाइन पर दो चीजों के लिए; यह या तो आपके कोड में एक बग है या आपके कोड को बाधित करने का इरादा है।

    return (   (   propVal.PropertyId == context.Definition.Id
                && !repo.ParentId.HasValue)
            || (   repo.ParentId == propVal.ParentId
                && (   (   propVal.SecondaryFilter.HasValue
                        && context.SecondaryFilter.HasValue 
                        && propVal.SecondaryFilter.Value == context.SecondaryFilter)
                    || (   !context.SecondaryFilter.HasValue
                        && !propVal.SecondaryFilter.HasValue))));

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

ध्यान दें कि (cond1 && cond2) || (! cond1 && cond3) के रूप में लिखा जा सकता है

cond1 ? cond2 : cond3

जिससे गंदगी कम होगी। मैं लिखूंगा

if (propVal.PropertyId == context.Definition.Id && !repo.ParentId.HasValue) {
    return true;
} else if (repo.ParentId != propVal.ParentId) {
    return false;
} else if (propVal.SecondaryFilter.HasValue) {
    return (   context.SecondaryFilter.HasValue
            && propVal.SecondaryFilter.Value == context.SecondaryFilter); 
} else {
    return !context.SecondaryFilter.HasValue;
}

Answer 11

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

आदर्श रूप से, मुझे लगता है कि आप गुणों की तुलनात्मक रूप से करेंगे, इसलिए आपके पास एक नई विधि निर्धारित नहीं है या यदि आप हर बार गुणों के एक नए सेट की तुलना करना चाहते हैं।

मुझे c # के बारे में निश्चित नहीं है, लेकिन जावास्क्रिप्ट में कुछ इस तरह से बेहतर होगा और कम से कम MatchesDefinitionId और MatchesParentId को बदल सकता है

function compareContextProp(obj, property, value){
  if(obj[property])
    return obj[property] == value
  return false
}

Comments

C # में ऐसा कुछ लागू करने के लिए कोई समस्या नहीं होनी चाहिए।

— स्नूप

मैं यह नहीं देख रहा हूं compareContextProp(propVal, "PropertyId", context.Definition.Id)कि ओपी के बुलियन संयोजन की तुलना में ~ 5 कॉल के बूलियन संयोजन को पढ़ना कितना आसान होगा propVal.PropertyId == context.Definition.Id। यह काफी लंबा है और कॉल साइट से किसी भी जटिलता को छिपाने के बिना एक अतिरिक्त परत जोड़ता है। (अगर यह मायने रखता है, तो मुझे

— नीचा