प्रोग्रामिंग तकनीकों का अति प्रयोग या दुरुपयोग [बंद]

Question

क्या प्रोग्रामिंग में ऐसी कोई तकनीक है जो आपको अधिक उपयोग में आती है (आईई ने जो किया जाना चाहिए उससे अधिक उपयोग किया) इसके साथ हल करें।

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

Comments

मैं मानता हूं कि IE का उपयोग उस तरीके से अधिक किया जाना चाहिए, जैसा कि मुख्य रूप से गैर-प्रोग्रामर द्वारा किया जाता है। । ।

— एरिक विल्सन

@FarmBoy - मुझे लगता है कि उनका मतलब IE था: "Ie" का अर्थ है "के लिए बस", जो लैटिन में पूरी तरह से लिखा गया है 'आईडी एस्ट' है।

— राफेल

अब यह तय :)

— Anto

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

— ChrisF

@ राहेल - मैं मजाक कर रहा था, बिल्कुल। शिक्षा के लिए धन्यवाद।

— एरिक विल्सन

Answer 1

कोड में टिप्पणियाँ

मेरी इच्छा है कि विश्वविद्यालय के प्रोफेसर यह समझें कि उन्हें अपने विद्यार्थियों को 10 पंक्तियों को लिखने के लिए पढ़ाने की आवश्यकता नहीं है, यह कहते हुए कि निम्नलिखित कोड लूप के लिए है, 1 से लेकर x की संख्या तक है। मैं कोड में देख सकते हैं!

उन्हें पहले स्व-दस्तावेजीकरण कोड लिखना सिखाएं, फिर पर्याप्त रूप से स्व-दस्तावेजीकरण दूसरा नहीं हो सकता है। सॉफ्टवेयर की दुनिया एक बेहतर जगह होगी।

Comments

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

— वुट 4Moo

@ Woot4Moo: यदि आप पढ़ते हैं Clean Code, तो फाउलर स्पष्ट रूप से बताता है कि आउट-ऑफ-डेट दस्तावेज़ बिना किसी दस्तावेज़ से भी बदतर है, और यह कि सभी टिप्पणियों में बासी बनने और कोड वे दस्तावेज़ से दूर जाने की प्रवृत्ति है। यह पूरी पुस्तक स्व-दस्तावेज कोड लिखने के बारे में है।

— स्कॉट व्हिटलॉक

करने के लिए उन्हें शिक्षण की जगह कोड के साथ टिप्पणी ... एक अच्छी शुरुआत होगी

— Shog9

+1। मैंने वास्तव में वास्तविक विश्व कोड में निम्नलिखित देखा है: "loopVar ++; // increment loopVar"। AAAAAAAAAAAAARRRRRGH!

— बॉबी टेबल्स

@ बिल: मेरा मानना ​​है कि आपको सामान्य तर्क और नियंत्रण संरचनाओं के दस्तावेज की आवश्यकता नहीं है, भले ही वे अपेक्षाकृत जटिल हों। असल में, कुछ भी जो एक अच्छा डेवलपर जो भाषा जानता है उसे कोड का विश्लेषण करके काम करने में सक्षम होना चाहिए, टिप्पणी करने की आवश्यकता नहीं होनी चाहिए। जैसे। उनके अंदर कुछ विराम के साथ छोरों के लिए नेस्टेड का एक सेट, लेकिन जो भी टिप्पणी की जानी चाहिए वह अनुप्रयोग-विशिष्ट तर्क है कि कोड उन निर्णयों को क्यों बनाता है: उदा। "यदि एक नया प्रोग्रामर कल कंपनी में शुरू होता है और कोड को देखता है, तो क्या यह टिप्पणी संकेत के बिना समझ में आएगा?"

— बॉबी टेबल्स

Answer 2

सिंगलटन डिजाइन पैटर्न।

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

Comments

मैं हर दिन एक रूपरेखा के लिए इस खराब डिज़ाइन वाले बहाने का उपयोग करता हूं। codeigniter.com/user_guide/lbooks/email.html उन्हें लगता है कि OOP कार्यों के साथ पूर्वसर्ग कर रहा है $this->। PHP एक सड़ी हुई भाषा है, इसलिए मैं रूपरेखाओं के उत्कृष्ट होने की उम्मीद नहीं कर सकता।

— कीयो

मुझे लगता है कि कोई भी प्रोग्रामर जो एक सिंगलटन को लागू करता है और पश्चाताप नहीं करता है वह पाप के लिए एक ज्वलंत नरक में जलाएगा (वह) उसने (या उसने) पाप किया है।

मैंने अपने पेशेवर करियर में एक बार (एक मल्टीटास्किंग संदर्भ में) एक सिंगलटन को लागू किया और मुझे इसे फिर से लिखकर अपने पाप के लिए पछताना पड़ा।

— Spoike

सिंगलटन कुछ चीजों के लिए उपयोगी हो सकते हैं, लेकिन लगभग हमेशा उपयोग किए जाते हैं जब उन्हें नहीं होना चाहिए। इसका मतलब यह नहीं है कि सिंग्लेटों का उपयोग कभी नहीं किया जाना चाहिए - सिर्फ इसलिए कि किसी चीज का दुरुपयोग किया जाता है इसका मतलब यह नहीं है कि इसे सही तरीके से उपयोग नहीं किया जा सकता है।

— विन्यासकर्ता

@ रापेल: यही कारण है कि मेरा मानना ​​है कि डिजाइन पैटर्न का अध्ययन करना अच्छी बात नहीं है।

— विन्यासकर्ता

Answer 3

गूंगा प्रोग्रामिंग की रक्षा के लिए सबसे बुरी बात है। सब कुछ एक कोशिश की पकड़ में डाल दिया और पकड़ के साथ कुछ नहीं कर रहा

        try
        {
            int total = 1;
            int avg = 0;
            var answer = total/avg;
        }
        catch (Exception)
        {

        }

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

Comments

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

— स्टीव ३४

@ आपके द्वारा बताए गए मामले में एक दुर्लभ किनारे की स्थिति है। एक और जिसके बारे में मैं सोच सकता हूं कि वह कोडिंग लॉगिंग है - यदि लॉगिंग स्वयं विफल हो जाती है, तो अपवाद को लॉग करने या ऐप को बाधित करने का कोई मतलब नहीं है।

— dbkk

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

— स्टीव ३४

त्रुटि अगले पर शुरू

— जे.के.

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

— स्टीव

Answer 4

अपनी समस्याओं को हल करने के बजाय स्टैकऑवरफ्लो पर रिलायंस ने इसे कठिन तरीके से सुलझाया।

नए प्रोग्रामर जो एसओ (बहुत बार) के ज्ञान के धन का पता सोचते हैं और सामान बाहर की कोशिश कर रहे हैं।

मेरे दिन में हमें किताबों से कोड करना पड़ता था, कोई इंटरनेट नहीं, कोई एसओ नहीं। अब मेरे लॉन से निकलें।

Comments

मुझे स्वीकार करना चाहिए, मैं एसओ पर कुछ सवालों की धृष्टता पर भड़कता हूं। या तो क्योंकि उन्हें हर दिन कई बार पूछा जाता है और उन्होंने स्पष्ट रूप से बिल्कुल नहीं खोजा है; या इससे भी बदतर, वे समुदाय को एक नि: शुल्क आउटसोर्सिंग सेवा के रूप में मानते हैं।

— परिक्रमा

@dbkk: stackoverflow.com/questions/4665778/… -> पहली टिप्पणी "क्या आपने कभी यह कोशिश की थी?"

— मैथ्यू एम।

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

— कोनराड रुडोल्फ

@ कोनराड रूडोल्फ: यह तरीका अच्छा और समझदार है, प्रश्नों को पढ़ना, अच्छी तरह से खोजना। पूछना सबसे अच्छा होता है जब पूछने वाले के पास एक ऐसा ढांचा हो, जिसके जवाबों को समझना हो। बहुत बार लोग ऐसे प्रश्न पूछते हैं जिन्हें वे (अभी तक) समझने की क्षमता नहीं रखते हैं।

— परिक्रमा

समस्या यह है कि SO ने बहुत आसान प्रश्न पूछने / उत्तर देने के लिए बहुत से रिपीट देकर इसे प्रोत्साहित किया जो कि सरल Google खोज के साथ उत्तर दिया जा सकता है। बहुत कठिन सवाल लोग केवल इसलिए जवाब देते हैं क्योंकि वे वास्तव में चाहते हैं।

— एडेप्टर

Answer 5

OOP जाहिर है। यह बहुत मूल्यवान है, लेकिन जब इसका दुरुपयोग किया जाता है तो यह आसानी से स्पष्ट कोड को आसानी से अस्पष्ट कर सकता है (R4 में S4 प्रोग्रामिंग के कुछ उदाहरण दिमाग में आते हैं), और एक जबरदस्त ओवरहेड दे सकते हैं जो अनावश्यक है और प्रदर्शन पर आपके बड़े समय का खर्च कर सकता है।

एक और बात यह है कि (उदाहरण के लिए पर्ल) ओओपी अक्सर एक ही चीज को दूसरे तरीके से लिखने के लिए नीचे आता है: result = $object ->function(pars)इसके बजाय result = function(object, pars)यह कभी-कभी समझ में आता है, लेकिन जब प्रक्रियात्मक प्रोग्रामिंग के साथ मिलाया जाता है तो यह कोड को बहुत भ्रमित कर सकता है। और इसके अलावा, आप बस अधिक ओवरहेड का परिचय देते हैं जहां यह डिजाइन में सुधार नहीं करता है। यह नीचे आता है कि सिंगलटन पैटर्न के बारे में क्या कहा गया है: इसका उपयोग किया जाना चाहिए, लेकिन हर चीज पर नहीं।

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

Comments

@ क्रैज: मैं खुद OOP का उपयोग करता हूं, लेकिन मेरे क्षेत्र में (वैज्ञानिक कंप्यूटिंग) प्रदर्शन बहुत बड़ी बात है, और OOP का अक्सर वहां दुरुपयोग होता है क्योंकि आजकल सभी छात्रों को जावा मिलता है। यह बड़ी समस्याओं से निपटने के लिए, अवधारणा के लिए और बहुत कुछ है। लेकिन अगर आप BioPerl में उदा डीएनए अनुक्रमों के साथ काम करते हैं, तो हर बार वस्तुओं का उपयोग करते हुए और गेटर्स और सेटर्स के साथ लगातार काम करके गणना समय को दस गुना बढ़ा सकते हैं। जब आपका कोड कुछ घंटों के बजाय कुछ दिन चल रहा हो, तो यह अंतर वास्तव में मायने रखता है।

— जोरिस मेस

@ क्रैज: मेथड चैनिंग (जैसे Foo.DoX().DoY().DoZ()) अच्छा है, लेकिन, यह निश्चित रूप से कुछ के बारे में जाने का एकमात्र तरीका नहीं है। समारोह रचना (जैसे doZ . doY . doX $ fooएक पूरी तरह से वैध विकल्प है।

— Anon।

@ जॉरिस: एक ऐसी चीज जिसके बारे में मैं लंबे समय से सोच रहा था (खुद एक बायोइनफॉरमैटिशियन): यदि प्रदर्शन इतना ही मायने रखता है, तो C ++ के बजाय पहले स्थान पर पर्ल का उपयोग क्यों करें? यदि आप एक कारक 10 को रनटाइम (वैध चिंता!) से शेव करने के बारे में चिंतित हैं तो C ++ में स्विच करने से आपको तुरंत संतुष्टि मिलती है। बेशक, भाषा बेकार है ... लेकिन फिर, पर्ल करता है ... और C ++ के लिए अच्छे जैव सूचना विज्ञान पुस्तकालय हैं।

— कोनराड रुडोल्फ

@ कोनराड: यह निर्भर करता है। BioPerl के पास यकीनन सभी भाषाओं के जैव सूचना विज्ञानियों के लिए सबसे अधिक पैकेज हैं (I reckon Python हालांकि पकड़ रहा है)। साथ ही, पर्ल में बहुत काम किया गया है और एक स्क्रिप्ट को अपनाना C ++ में सब कुछ फिर से लिखने से ज्यादा आसान है। अंत में, यह एक पूर्ण आवेदन लिखने की सेवा नहीं करता है जब एक स्क्रिप्ट करेगा। लगता है यही कारण है कि पर्ल अभी भी बहुत कुछ है। और ईमानदारी से, मुझे कोई आपत्ति नहीं है, मुझे भाषा पसंद है। यह अभी भी सबसे अच्छा है जो मुझे स्ट्रिंग और फ़ाइल काम के लिए पता है। गणना स्पष्ट रूप से अन्य भाषाओं में की गई है और वापस जुड़ी हुई है (जो बहुत आसान है)।

— जोरिस मेय्स

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

— जोरिस मेय्स

Answer 6

ASP.NET वेबफॉर्म में कई साल बिताने के बाद, मुझे स्पष्ट रूप से कहना होगा:

स्मार्ट यूआई

जबकि वेबफॉर्म में स्तरित, परीक्षण योग्य एप्लिकेशन बनाना पूरी तरह से संभव है, विज़ुअल स्टूडियो डेवलपर्स के लिए अपने यूआई कोड के चारों ओर अटे पड़े एप्लिकेशन लॉजिक के साथ अपने डेटा-सोर्स से कसकर बंधने के तरीके पर एक क्लिक करने के लिए बहुत आसान बनाता है।

स्टीव सैंडरसन ने अपने प्रो ASP.NET MVC की किताब में इस प्रतिरूप को बहुत बेहतर बताया है:

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

Comments

GUI कम से कम कुछ प्रकार के विनिर्देशन कोड का पालन करना चाहिए। मुझे नहीं लगता कि उनके द्वारा बताए गए प्रोग्रामर अगर कोई खाली पाठ फ़ाइल के बजाय प्रस्तुत करते हैं तो बेहतर होगा।

@qpr, मैं उस के बारे में नहीं जानता। यदि उनके पास एक खाली पाठ फ़ाइल होती है तो वे कुछ भी करने में सक्षम नहीं हो सकते हैं (जो कि केवल एक बोनस हो सकता है)।

— केन हेंडरसन

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

— रॉबर्ट रॉसनी

एक हजार बार यह। मैं भी अनुभवी .NET डेवलपर्स को इस "पैटर्न" पर भरोसा करते हुए देखता हूं क्योंकि यह समझ या अलगाव की चिंता से आसान है। भले ही वे ड्रैग-एंड-ड्रॉप विज़ार्ड्स का उपयोग नहीं करते हैं, .NET वेबफॉर्म्स विकास में सबसे आम "पैटर्न" कोड-पीछे की घटनाओं में सब कुछ करना है और आवश्यकतानुसार कोड / पेस्ट कोड।

— वेन मोलिना

Answer 7

मुझे यह कभी-कभार दिखाई देता है और यह आमतौर पर बूलियन अभिव्यक्तियों को पूरी तरह से समझने के परिणामस्वरूप नहीं होता है।

if (someCondition == true)

Comments

कोड को अधिक स्पष्ट बनाने का फायदा है

— पेमदास

मुझे लगता है कि इस सवाल पर एक नज़र क्रम में है: programmers.stackexchange.com/questions/12807/…

— gablin

मैं ऐसा नहीं करता, लेकिन गंभीरता से, इस पर विचार करें। वहाँ बाहर बहुत बुरा का एक नरक है। :)

— 22

यदि आपने अपने चर को ठीक से नाम दिया है, उदाहरण के लिए boolशुरुआत के साथ isया has, आपको अपने कोड को अधिक स्पष्ट करने की आवश्यकता नहीं है = true।

— कोई नहीं

@DisgruntledGoat क्योंकि यह सभी में इस्तेमाल नहीं होना चाहिए

— कोरी

Answer 8

Reimplementing कार्यक्षमता, या तो अपने अस्तित्व की अज्ञानता की वजह से या क्योंकि अनुकूलन के लिए एक कथित जरूरत के कोर (या अन्यथा प्रदान की गई)।

Comments

सीखना एक अपवाद है। किसी भी चीज का अध्ययन करते समय, अक्सर "पहिया को फिर से मजबूत करना" फायदेमंद होता है।

— मैक्सएम

सुनिश्चित करने के लिए - मुझे निर्दिष्ट करना चाहिए कि यह उत्पादन सॉफ्टवेयर बनाते समय ही प्रासंगिक है।

— l0b0

सुरक्षा से संबंधित किसी भी चीज़ को लागू करते समय यह विशेष रूप से बुरा है। अच्छा सुरक्षा सॉफ्टवेयर उन हमलों को रोकता है जिनके बारे में ज्यादातर लोग कभी सोचते भी नहीं हैं।

— डेविड थॉर्नले

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

— वेन मोलिना

Answer 9

विरासत।

लागू न करें-जहां यह समझ में नहीं आता है।

Comments

समस्या यह है कि सहज ज्ञान युक्त "है" एक बहुत बार समझ में आता है (विशेष रूप से हर कार्यान्वयन / अनुबंध संबंध के बाद बोलचाल की भाषा में "एक-एक" के रूप में व्यक्त किया जा सकता है)। यह महसूस करने के लिए OOP की एक ठोस समझ की आवश्यकता है कि यह वास्तव में एक गलती है, और यह कि विरासत और इंटरफ़ेस कार्यान्वयन मौलिक रूप से अलग हैं।

— कोनराड रुडोल्फ

@ कोनराड - बिल्कुल सहमत। मैं लोगों को रचना के साथ शुरू करने , इंटरफेस पर आगे बढ़ने और विरासत पर विचार करने के लिए प्रोत्साहित करने का प्रयास करता हूं। (अंगूठे के एक नियम के रूप में, बिल्कुल)। लेकिन हो सकता है कि यह मेरी वीबी पृष्ठभूमि की बात कर रहा हो ... ;-)

— माइक वुडहाउस

यह काफी हद तक एक भाषा डिजाइन प्रश्न है, हालांकि। जावा या सी # जैसी भाषाओं में आपको "रचना (कार्यान्वयन) वंशानुक्रम पसंद करना चाहिए" का कारण यह है कि कार्यान्वयन विरासत उन भाषाओं में बेकार है। कुछ लोग विरासत के अति प्रयोग के लिए बर्ट्रेंड मेयर के ऑब्जेक्ट-ओरिएंटेड सॉफ्टवेयर निर्माण की आलोचना करते हैं , लेकिन जब आप वास्तव में एफिल (पुस्तक में प्रयुक्त भाषा) को देखते हैं, तो आपको पता चलता है कि यह कार्यान्वयन विरासत के लिए डिज़ाइन किया गया था , और इस प्रकार यह वास्तव में विरासत का उपयोग करने के लिए ठीक है रचना। में है कि मामला है, कम से कम।

— जोर्ग डब्ल्यू मित्तग

Answer 10

ऑफ-द-शेल्फ सॉफ्टवेयर को अनुकूलित करना।

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

Comments

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

— जेफओ

Answer 11

एक डीबगर के रूप में अनिवार्य का उपयोग करना।

अनिवार्य चेतावनियों को अनदेखा करना या उन्हें पूरी तरह से बंद कर देना।

सार्वत्रिक चर।

Comments

"एक डिबगर के रूप में संकलक का उपयोग करना" क्या गलत है? एक संकलक जो आपके कोड में त्रुटियों को इंगित करने में सक्षम है, इससे पहले कि वे रनटाइम पर एक मुद्दा बन जाए, एक जबरदस्त लाभ है।

— मेसन व्हीलर

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

— गाब्लिन

समस्या तब है जब आप प्रोग्राम की शुद्धता सुनिश्चित करने के लिए कंपाइलर पर निर्भर होने लगते हैं। क्या यह संकलन था? नहीं, मुझे इस छोटे से खंड में जाने दें और देखें कि क्या यह तय हो गया है। क्या यह संकलन था? नहीं, मुझे यहां और वहां एक * जोड़ने दें और देखें कि क्या संकलित है। ... ect। जाहिर है, यह टाइपो को ठीक करने के लिए उपयोगी है

— पेमदास

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

— मेसन व्हीलर

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

— कोनराड रुडोल्फ

Answer 12

सभी डिजाइन पैटर्न।

वे नमक या चीनी की तरह हैं। आपके भोजन पर उनमें से कुछ इसे महान बनाते हैं, बहुत सारे, आपके भोजन को बेकार कर देते हैं।

मुझे गलत मत समझो डिजाइन पैटर्न अद्भुत तकनीक हैं। मैंने उनका भरपूर इस्तेमाल किया। लेकिन कभी-कभी, मुझे प्रोग्रामर मिलते हैं, (उनमें से कुछ मेरे पूर्व-बॉस), जिनके पास ये "आपको एक डिज़ाइन पैटर्न का उपयोग करना है", भले ही समस्या से मेल न खाता हो !!!

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

मुझे उम्मीद है कि "डिज़ाइन पैटर्न" पुस्तक के एक नए संस्करण में, मौजूदा लोगों के लिए एक नए पैटर्न के रूप में इसका जोड़ा जाएगा।

Comments

मैं कभी भी डिज़ाइन पैटर्न का उपयोग नहीं करता, हालांकि वे कभी-कभी मेरे कोड में स्वाभाविक रूप से उभर आते हैं।

— विन्यासकर्ता

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

— वेन मोलिना

@configurator जब मैं डिज़ाइन पैटर्न के बारे में पढ़ता हूं; मुझे यह भी पता चलता है कि मुझे और अन्य डेवलपर्स जहां पहले से ही उनमें से कुछ का उपयोग कर रहे हैं ;-)

— umlcat

Answer 13

प्रवाह नियंत्रण के रूप में अपवादों का उपयोग करना। इस उत्तर के समान , लेकिन अलग।

अपवादों को निगलना बुरा रूप है क्योंकि यह कोड में बग ढूंढने के लिए रहस्यमय, कठिन है। दूसरी ओर, प्रवाह नियंत्रण के रूप में अपवादों का उपयोग करना बुरा है, क्योंकि यह कोड को जितना हो सकता है उससे कहीं अधिक अक्षम बनाता है, और वैचारिक रूप से मैला है।

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

Comments

अयोग्य कोड बनाने के लिए अपवाद आपकी भाषा पर निर्भर करता है - स्टैक फ्रेम आदि का निर्माण करना। चीख़ में, आपके स्टैक का पूरी तरह से पुन: उपयोग किया जाता है, इसलिए अपवादों का उपयोग करने या न करने के बीच कोई अंतर नहीं है। (दूसरे शब्दों में, अपवाद पुस्तकालय, नहीं भाषा का हिस्सा हैं।) हालांकि, यह है भ्रामक अपवाद नियंत्रित नियंत्रण प्रवाह के साथ काम: lshift.net/blog/2011/01/04/try-again-with-exceptions शो एक लूप-उपयोग-अपवाद जो मैंने हाल ही में पाया।

— फ्रैंक शियरर

अंतिम पैराग्राफ के बारे में, फिर से, यह आपकी भाषा पर निर्भर करता है। आम लिस्प में अपवाद ("स्थितियां") अपवादों के अधिकांश भाषाओं के विचारों का एक सख्त सुपरसेट हैं। यहाँ उदाहरण देखें: gigamonkeys.com/book/… सब कुछ के साथ, आप बहुत दूर जा सकते हैं!

— फ्रैंक शियरर

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

— स्टीव

Answer 14

मैं अत्यधिक डेटा छिपाने के माध्यम से अनम्यता के साथ जा रहा हूं।

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

परेशानी यह है कि जैसा कि सभी संदर्भों के लिए सही-संतुलन-के लिए, यह अनुभव लेता है।

Answer 15

आंतरिक सरणियों को उजागर करना

    public class Data {
    int[] x;

    public void setArray(int[] x) {

        this.x = x;
    }

    public int[] getArray() {

        return x;
    }
}

Http://www.oracle.com/technetwork/java/seccodeguide-139067.html के अनुसार

लौटने से पहले उत्परिवर्तित वस्तुओं को कॉपी करें, जब तक कि राज्य साझा करने का इरादा न हो।

Answer 16

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

उदाहरण के लिए, इसे सीधे StackOverflow थ्रेड से लिया गया है:

// ECMAScript
var thing, things_by_type = {};
for (var i = 0; i < things.length; i++) {
    thing = things[i];
    if(things_by_type[thing.type]) {
        things_by_type[thing.type].push(thing);
    } else {
        things_by_type[thing.type] = [thing];
    }
}

# Ruby
things_by_type = {}
things.each do |thing|
  (things_by_type[thing.type] ||= []) << thing
end

वे दोनों एक ही काम कर रहे हैं। लेकिन मुझे नहीं पता कि वे क्या कर रहे हैं। सौभाग्य से, सवाल वास्तव में बताता है कि वे क्या कर रहे हैं, इसलिए मैं उन्हें निम्नानुसार फिर से लिखने में सक्षम था:

// ECMAScript
things.reduce(function (acc, thing) {
    (acc[thing.type] || (acc[thing.type] = [])).push(thing);
    return acc;
}, {});

# Ruby
things.group_by(&:type)

// Scala
things groupBy(_.type)

// C#
from thing in things group thing by thing.Type // or
things.GroupBy(thing => thing.Type);

कोई लूप नहीं है, और कोई भी परिवर्तनशील स्थिति नहीं है। ठीक है, ठीक है, कोई स्पष्ट लूप और कोई लूप काउंटर नहीं।

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

Comments

मुझे विश्वास है कि आपके "निश्चित" ECMAScript की दूसरी पंक्ति में (acc[thing.type] || (acc[thing.type] = [])), , unless you want to add दो बार सूची में `= [चीज़] का विरोध करना चाहिए ... या क्या मुझे कुछ याद आ रहा है?

— ऑस्टिन हाइड

@ ऑस्टिन हाइड: आप सही कह रहे हैं।

— जोर्ग डब्ल्यू मित्तग

उस कार्यक्रम का उदाहरण कई प्रोग्रामर के लिए समझ से बाहर है। यह बहुत अधिक वाक्यात्मक चाल पर निर्भर करता है। जूनियर डेवलपर्स के लिए लूप में स्पष्टता का लाभ है।

— जोरी सेब्रेट्स

Answer 17

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

Comments

सिद्धांत में सहमत; mocks उपयोगी होते हैं, लेकिन आप नहीं करते है उन्हें करने के लिए।

— वेन मोलिना

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

— फ्रैंक हिलमैन

Answer 18

डेल्फी प्रोग्रामर दुनिया भर में पिछले दो वर्षों से पता लगा रहे हैं कि व्हर्लसेल यूनिकोड रूपांतरण के कारण बाइट्स को स्टोर करने के लिए चरित्र सरणियों का उपयोग करना कितना बुरा है।

और, "जल्द ही" हम सीखेंगे कि पूर्णांकों को सूचियों में संग्रहीत करना कितना बुरा है जब हम 64-बिट्स में परिवर्तन करना चाहते हैं ।

Comments

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

— मेसन व्हीलर

Answer 19

गुण। मुझे पता है कि यह विवादास्पद है, लेकिन मुझे लगता है कि गुणों को बहुत अधिक मात्रा में उपयोग किया जाता है।

इन दो पंक्तियों में क्या अंतर है?

public string Property { get; set; }

public string Field;

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

Comments

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

— वेन मोलिना

@Wayne: कैसे बदल रहा है ;करने के लिए { get { ... } set { ... } }बदल रहा है की तुलना में किसी भी अधिक काम { get; set; }करने के लिए { get { ... } set { ... } }?

— विन्यासकर्ता

अब जब मैं इसके बारे में सोचता हूं, तो यह उचित है।

— वेन मोलिना