कोड के पुन: उपयोग के बारे में

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


ऐसी निराशा के कारण भी कई हैं। सबसे पहले, OOP के लिए यह रवैया उच्च उम्मीदों का परिणाम हो सकता है, लेकिन फ्रेड ब्रूक्स ने बीस साल पहले लिखा था कि आपको "चांदी की गोलियों" की प्रतीक्षा नहीं करनी चाहिए जो कि परिमाण के क्रम से प्रोग्रामर की उत्पादकता बढ़ा सकती है। दूसरे, पीएलओ के गंभीर समर्थकों में से कोई भी (जैसे कि ग्रैडी बुच या बर्ट्रेंड मेयर) ने वादा किया कि सब कुछ सरल होगा। ओओपी कोई जादू की छड़ी नहीं है जो कैंडी को किसी भी यूजी से बाहर कर देगा, यहां तक ​​कि एक आवरण भी जिसका पुन: उपयोग किया जा सकता है।

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

मुझे ऐसा लगता है कि पुन: उपयोग की ऐसी विकट स्थिति के दो कारण हैं: (1) डेवलपर्स पुन: उपयोग पर बहुत कम ध्यान देते हैं और (2) डेवलपर्स पुन: उपयोग के लिए बहुत अधिक ध्यान देते हैं। हां, यह लगता है, कम से कम, बेवकूफ है, लेकिन मुझे थोड़ा rephrase करें: पुन: उपयोग के साथ समस्या यह है कि प्रयास समय पर नहीं किए जाते हैं और हमेशा नहीं जहां आपको आवश्यकता होती है ।

मानक सॉफ्टवेयर जीवन चक्र

आरंभ करने के लिए, आइए सॉफ्टवेयर विकास के एकल पुनरावृत्ति के विशिष्ट जीवन चक्र को देखें:



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

सामान्य तौर पर, इसके साथ कुछ भी गलत नहीं होता है जब तक कि सामान्यीकरण प्रक्रिया प्रणाली के डिजाइन को प्रभावित करना शुरू नहीं करती है, समय की देरी और जटिलता के बढ़ने की ओर ले जाती है, बजाय इसे लड़ने के।

समय से पहले सामान्यीकरण

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

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

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

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

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

संशोधित गर्भाधान जीवन चक्र

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

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

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

निष्कर्ष

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

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

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