🆗 👨🏼‍⚕️ 🙏🏼 डैमेज-ओरिएंटेड प्रोग्रामिंग 👄 ◽️ 👩🏻‍🔧

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

क्षतिग्रस्त - एक दोष , हीन होना। हानिकारक, अपर्याप्त।

विरासत

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

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

छद्म कोड विरासत उदाहरण:

function getCustName(custID) { custRec = readFromDB("customer", custID); fullname = custRec[1] + ' ' + custRec[2]; return fullname; } function getCustEmail(custID) { custRec = readFromDB("customer", custID); fullname = custRec[1] + ' ' + custRec[2]; /*************** * 4/15/96 git :  email  *      ***************/ return custRec[17]; }

getCustEmail फ़ंक्शन को getCustEmail फ़ंक्शन से विरासत में मिला था, जब ईमेल समर्थन को एप्लिकेशन में getCustName गया था। इस तरह से इनहेरिटिंग कोड गलती से कार्यक्रम में नए बग को पेश करने से बचता है।

प्रकार बहुरूपता विरासत के प्रकारों में से एक है। इसमें, कोड को इनहेरिट करते समय, स्रोत चर के प्रकार बदल दिए जाते हैं।

प्रतिरूपकता

मॉड्यूलर प्रोग्राम को कई फाइलों में विभाजित किया गया है जिसमें टिप्पणियों के साथ एक सामान्य हेडर है। मॉड्यूल में आमतौर पर शामिल हैं:

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

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

अवयव और पुस्तकालय

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

कैप्सूलीकरण

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

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

बहुरूपता

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

उदाहरण के लिए, उपरोक्त कार्यों को विरासत और बहुरूपता का उपयोग करके एक एकल बहुरूपी फ़ंक्शन में फिर से लिखा जा सकता है:

 function getCustData(custId, what) { if (what == 'name') { custRec = readFromDB("customer", custId); fullname = custRec[1] + ' ' + custRec[2]; return fullname; } else if (what == 'email') { custRec = readFromDB("customer", custId); fullname = custRec[1] + ' ' + custRec[2]; /*************** * 4/15/96 git :  email  *      ***************/ return custRec[17]; } /* ...   . */ }

बहुरूपता भी गैर-नियतात्मक ट्यूरिंग परिमित राज्य मशीनों के साथ जुड़ा हुआ है, जिसे आप कंप्यूटर विज्ञान पाठ्यक्रम से याद कर सकते हैं।

इसमें शामिल हैं

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

आभासी कक्षाएं और कार्य

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

 function calcSalesTax(price, isTaxable, state) { /**************************************** * * TO DO: * *     *  - ,    * * ****************************************/ /** 02/07/99 git --     **/ return price * (7.25 / 100.0); }

एक नाजुक आधार वर्ग एक वर्ग या मॉड्यूल है जो एक परियोजना में लंबे समय से मौजूद है, कोई भी परिवर्तन जिसमें संपूर्ण अनुप्रयोग टूट जाता है।

अधिभार

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

प्रलेखन

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

प्रलेखन लेने के लिए एक महान समय है जब कोई व्यक्ति रोजगार समाप्ति के लिए आवेदन करता है। दो हफ्तों में एक कर्मचारी को बाहर काम करना चाहिए, यह उसके द्वारा विकसित किए गए सभी कोड के लिए प्रलेखन लिखना अच्छा होगा।

टिप्पणियों के साथ कोड को रोकना, इसके संचालन के तंत्र की घोषणा करने से ध्यान भटक जाता है और संकलन धीमा हो जाता है। इसलिए, प्रोग्रामर जो त्रुटिपूर्ण प्रोग्रामिंग की "सर्वोत्तम प्रथाओं" का पालन करते हैं, वर्कफ़्लो अकाउंटिंग सिस्टम में प्रलेखन रखते हैं ताकि प्रोग्रामर गलती से इसे मिटा न सकें।

संस्करण नियंत्रण

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

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

निष्कर्ष

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

एक अनुवादक से: हालाँकि यह लेख 2007 में भी प्रकाशित हुआ था, लेकिन इसने प्रासंगिकता नहीं खोई है। " असमर्थित सॉफ्टवेयर कैसे विकसित करें " लेख में लिंक के लिए vovochkin का धन्यवाद।

डैमेज-ओरिएंटेड प्रोग्रामिंग