बयानों के बहुत से उपयोग करने के नुकसान

Question

कोड पठनीयता के अलावा, यदि बयानों के बहुत सारे उपयोग करना बुरा क्यों है?

Answer 1

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

अगर (और बाकी) बयान आम तौर पर दर्शाता

क) Violation of Single responsibility Principle

ख) Strategy Design Pattern

Answer 2

if(A) 
{ 
}else 
if(B) 
{ 
}else 
if(C) 
{ 
}else 
if(D) 
{ 
}else 
{ } 

सभी if रों अभी भी हो "गणना" करने के लिए यह की तरह कुछ कर रही है "हे (एन)" होगा। जब संभव हो तो इसे टालना चाहिए और switch(Lalala)

Answer 3

कभी कभी प्रोसेसर आर्किटेक्चर की वजह से

में बाहर refactor करने की आवश्यकता का एक बहुत है, यह एक खोजने के लिए और अधिक कुशल है बिल्कुल शाखाओं से बचने के लिए रास्ता; इसे if कथन का नुकसान माना जा सकता है।

Answer 4

एक और संभावना - यह निर्भर करता है कि अगर कथन क्या कर रहे हैं। कुछ मामलों में, वे निर्णय ले सकते हैं जो उचित ढंग से डिज़ाइन किए गए क्लास पदानुक्रम द्वारा बेहतर होते हैं।

क्या आप कुछ उदाहरण पोस्ट कर सकते हैं यदि आपको बताए गए बयान खराब हैं?

Answer 5

प्रत्येक अगर आप लिखते हैं तो आपके द्वारा परीक्षण किए जाने वाले कोड पथों की संख्या बढ़ जाती है।

Answer 6

यदि कथन पाइपलाइन में एक स्टॉल का उत्पादन कर सकता है। आप पाइपलाइन खतरों here के बारे में पढ़ सकते हैं। इसलिए, बहुत ही महत्वपूर्ण महत्वपूर्ण अनुप्रयोगों के लिए एक बड़े लूप में बयान देने के लिए बहुत अच्छा विचार नहीं है। आधुनिक प्रोसेसर में शाखा भविष्यवाणी के बारे में this लेख, और शर्तों के विभिन्न बिंदुओं के बेंचमार्क भी देखें।

इसके अलावा, मुझे लगता है कि बहुत से लोग केस स्टेटमेंट के बारे में बात करते हैं। this एसओ धागा की जांच करें।

और अंत में, wiki article पाइपलाइन के बारे में जो शायद हर प्रोग्रामर को पढ़ना चाहिए था।

उम्मीद है कि यह मदद करता है।

Answer 7

चुसदाद सही है। स्विच संरचना कई से बेहतर है अगर अन्यथा। अगला दृष्टिकोण एनम का उपयोग स्विच कुंजी के रूप में करना है। यदि आप अपने स्विच में enum तत्वों में से एक का उल्लेख करना भूल गए हैं तो इस मामले में आपको चेतावनी मिलती है।

लेकिन यदि आप enum और switch का उपयोग कर रहे हैं, तो बेहतर डिज़ाइन के लिए आगे बढ़ें: बिल्कुल स्विच हटाएं!

अपने enum में अमूर्त व्यापार विधि घोषित करें। प्रत्येक enum तत्व के लिए इसे लागू करें। स्विच लागू करने के बजाय enumElement.theMethod() कॉल करें।

यहां एक उदाहरण है।

Foo.valueOf(System.getProperty("foo")).foo(); 

निम्नलिखित के साथ इस लाइन की तुलना करें::

enum Foo { 
    ONE { 
     public void foo() { 
      // do something 
     } 
    }, 

    TWO { 
     public void foo() { 
      // do something 
     } 
    }, 

    ; 
    public abstract void foo(); 
} 

यहाँ कोड इस का उपयोग करता है है

String foo = System.getProperty("foo"); 
    if("ONE".equals(foo)) { 
     //..... 
    } else if("ONE".equals(foo)) { 
     //..... 
    } else { 
     //..... 
    } 

मुझे लगता है कि कोई टिप्पणी नहीं की आवश्यकता है।

Answer 8

ठीक है, मुझे सवाल पूछना है, "क्या विरोध है"?

यदि आप स्विच स्टेटमेंट के विपरीत हैं, तो साथ ही पठनीयता कभी-कभी अधिक कुशल हो सकती है। एक निश्चित रूप से शाखाओं के नीचे एक नियम (निश्चित रूप से सी # में, दूसरों में होने की संभावना) के रूप में इसे संकलित करते समय केवल बयानों की श्रृंखला में बदल दिया जाएगा, लेकिन उस संख्या से परे इसे एक हैश-आधारित लुकअप में बदल दिया जाएगा और कूदो औसत मामले पर तेजी से होने की संभावना है।

वैकल्पिक रूप से, यदि आपके पास विभिन्न मामलों की सापेक्ष आवृत्ति का अच्छा ज्ञान है, तो आप कथन के सेट के साथ अधिक कुशल हो सकते हैं। जैसे यदि 95% मामले पहली शाखा से मेल खाते हैं, तो 4% दूसरे और 1% मैच बाकी के साथ मिलते हैं, यह 95% मामलों के लिए एक तुलना करके बेहतर प्रदर्शन कर सकता है और शायद उस मामले में ब्रांचिंग भी नहीं कर सकता है।

तो। शायद इस मामले में एक दक्षता लाभ है।

फिर भी, पठनीयता बहुत नरक के लिए मायने रखती है। एक चरम उदाहरण के रूप में, एक ट्यूरिंग-पूर्ण भाषा है जिसे केवल यह देखने के लिए डिज़ाइन किया गया था कि ट्यूरिंग-पूर्ण भाषा के लिए एक कंपाइलर कितना छोटा हो सकता है। इस डिजाइनर ने भाषा "brainf ** k" नाम दिया है। वास्तविक प्रोग्रामिंग में पठनीय कोड के महत्व पर यह स्वयं ही एक महान टिप्पणी है।

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

Answer 9

यदि आप स्वयं को उसी स्थिति के लिए if कथन लिखते हैं, तो यह प्रकार पदानुक्रम के उस हिस्से को बनाने के लिए और अधिक रखरखाव होगा।

कारण यह है कि यदि इस स्थिति के लिए तर्क बदलता है, तो आपको इसका उपयोग करने वाले प्रत्येक if कथन का शिकार करना होगा और इसे संशोधित करना होगा।

यदि वह तर्क क्लास पदानुक्रम में समाहित है, तो आपको केवल इसे एक बार बदलना होगा।