कोड कैसे लिखना है जो पुन: उपयोग किया जाएगा

पुन: उपयोग के लिए डिज़ाइन किया गया कोड सभी प्रोग्रामिंग परेशानियों के लिए एक रामबाण हो सकता है जो एक खतरनाक मिथक है। अब मैं समझाऊंगा कि क्यों।

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

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

ऐसा क्यों है?

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

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

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

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

यहाँ कुछ व्यावहारिक सुझाव दिए गए हैं कि कैसे कोड को पुन: प्रयोज्य बनाया जाए।

दोहराव से बचें

जैसा कि लिमोन सिंक्वेट ने ठीक ही कहा: “दोहराओ मत। सबसे पहले, आप खुद को दोहराते हैं, दूसरे, आप एक ही बात कहते हैं, और तीसरी बात, सभी ने पहले ही सुना है। ”

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

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

सुनिश्चित करें कि कक्षा / विधि / कार्य एक चीज के लिए जिम्मेदार है।

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

प्रत्येक प्रणाली एक विषय-उन्मुख भाषा के माध्यम से बनाई गई है, जो प्रोग्रामर द्वारा इस तरह की प्रणालियों का ठीक से वर्णन करने के उद्देश्य से बनाई गई थी। क्रिया इन भाषाओं में क्रिया की भूमिका को पूरा करती है, और कक्षाएं संज्ञा की भूमिका निभाती हैं। वे एक साथ, एक नियम के रूप में, किसी भी भाषा के संगठन का मूल स्तर बनाते हैं; तदनुसार, यदि आप उन्हें गुणवत्ता तरीके से लिखते हैं, तो आपका कोड उच्च गुणवत्ता का होगा।

फ़ंक्शन और कक्षाएं बनाने के लिए दो सुनहरे नियम हैं जिन्हें कई बार लागू किया जा सकता है, बस दो:

• उन्हें छोटा होना चाहिए
• उन्हें एक काम करना चाहिए, और अच्छी तरह से

यह मानता है कि नेस्टेड संरचनाओं को शामिल करने के लिए फ़ंक्शन पर्याप्त नहीं बढ़ना चाहिए। इसलिए, घोंसले का स्तर एक या दो से अधिक नहीं होना चाहिए। इस तकनीक के लिए धन्यवाद, कोड पढ़ना, पार्स और आत्मसात करना आसान हो जाता है।

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

विरासत का दुरुपयोग न करें

कभी-कभी हम, डेवलपर्स, परियोजना के दूर के भविष्य को देखने की कोशिश करते हैं और "क्या आप इसे ज़रूरत है" और "किसी दिन काम में आते हैं" विचारों के साथ अतिरिक्त कार्यों में फेंकना शुरू करते हैं। ऐसा मत करो। अब तक, यह आपके लिए काम में नहीं आया है, अब आपको इसकी आवश्यकता नहीं है और ज्यादातर मामलों में ... आपको इसकी आवश्यकता नहीं होगी (YAGNI के प्रसिद्ध सिद्धांत को समझने के लिए - आपको इसकी आवश्यकता नहीं है)। यह सिद्धांत वंशानुक्रम पर लागू होता है। इसे दर्ज न करें यदि आपको पूरा भरोसा नहीं है कि कार्यान्वयन कई बार दोहराया जाएगा।

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

"चूंकि उपवर्ग के पास मूल वर्ग के कार्यान्वयन विवरण तक पहुंच है, इसलिए अक्सर कहा जाता है कि विरासत में उल्लंघन होता है।"

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

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

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

निष्कर्ष में

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

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

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