सॉफ्टवेयर परियोजना और OOP विकास

एक सॉफ्टवेयर परियोजना के प्रभावी विकास के लिए व्यंजनों को माहिर करते हुए, मैंने अपने लिए उन कारणों को खोजने की कोशिश की, जो कि SOLID वास्तुकला के विकास के सिद्धांतों का उपयोग करने के लिए उपयोगी हैं (लेख में SOLID वास्तुकला के विकास के सिद्धांतों को कैसे नहीं समझा जाए )।

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

आम तौर पर स्वीकृत प्रोग्रामिंग प्रतिमानों के लिए इन अवधारणाओं की प्रयोज्यता का विश्लेषण करना दिलचस्प हो गया, उदाहरण के लिए, ओओपी के लिए। ठीक है, अगर इस काम का परिणाम आपके लिए उपयोगी होगा।

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

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

          ,      . 

सॉफ्टवेयर प्रोजेक्ट डेवलपमेंट

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

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

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

अन्य सभी स्थितियों में, प्रोग्रामर, अपने काम को कम से कम, एक संरचनात्मक रूप से जटिल परियोजना विकसित करना चाहिए, जो है:

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

यदि आप एक सॉफ्टवेयर परियोजना के विकास के लिए उपमाओं की तलाश करते हैं, तो आप एक जैविक प्रजाति के विकास को याद कर सकते हैं।

      "".     -       .       -  . 

प्रोग्रामर का काम आसान नहीं है, लेकिन प्रोग्रामर के पास "सहायक" है। यह सहायक हमारी दुनिया की संरचना में कहीं गहरे छिपा है, जिसमें दो विशेषताएं हैं:

• एक उपयोगी एल्गोरिदम लिखने और कई समान कार्यों के लिए इसका उपयोग करने की क्षमता,
• उनके समाधान में समान महान कार्यों की उपस्थिति।

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

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

यहां मैं विभिन्न क्षेत्रों से अमूर्तता का उपयोग करने के उदाहरणों को लिखने की कोशिश करूंगा।

एक सॉफ्टवेयर प्रोजेक्ट का बिल्डिंग ब्लॉक

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

घटक - कोड का एक टुकड़ा (प्रक्रिया, वर्ग, परिनियोजन घटक, आदि):

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

एक सॉफ्टवेयर परियोजना के विकास में पैटर्न

टर्म कंपोनेंट का उपयोग करना, सरल कानूनों का एक सेट तैयार करना संभव हो जाता है जो किसी सॉफ्टवेयर प्रोजेक्ट के विकास में मौजूद होते हैं। मैं इन पैटर्नों को निम्न कथनों के रूप में प्रस्तुत करूंगा, जिन्हें 3 श्रेणियों में विभाजित किया गया है।

1. किसी घटक के गुणों का वर्णन करने वाले विवरण।
   1.1। एक सही ढंग से लिखा घटक आवश्यक रूप से उपयोग किया जाता है और अधिक बार कई बार।
   1.2। प्रत्येक स्थान पर जहां घटक का उपयोग किया जाता है, उससे निरंतर व्यवहार की अपेक्षा की जाती है, जिसके परिणामस्वरूप एक दोहराव होता है।
   1.3। कई स्थानों पर घटक का उपयोग करते समय, परिणाम को उपयोग के प्रत्येक स्थान को संतुष्ट करना चाहिए।
   1.4। घटक में एम्बेडेड व्यवहार इस घटक के उपयोग के स्थानों पर प्रतिबंध बनाता है।
   1.5। घटक के उपयोग के प्रत्येक स्थान में, इसके सभी प्रतिबंध शामिल हो सकते हैं।
   1.6। एक घटक में कोई भी परिवर्तन इसकी सीमाओं को बदलता है और इसके उपयोग के सभी स्थानों के सत्यापन की आवश्यकता होती है, जो एक प्रोग्रामर को समय बर्बाद करने का कारण बनता है।
   1.7। एक उदाहरण में कोड के रूप में घटक लिखना उचित है, अर्थात, समान कोड के दोहराव को समाप्त करना आवश्यक है। यह एक घटक में बदलाव करते समय संपादन की संख्या को कम कर देगा।
2. प्रोग्रामर द्वारा एक नए कार्य के कार्यान्वयन में पैटर्न का वर्णन करने वाले विवरण।
   2.1। प्रोग्रामर द्वारा बिताए गए समय को कम करते हुए एक नए कार्य को लागू करने के लिए एक विकल्प चुनना उचित है।
   2.2। एक नया कार्य लागू करने के लिए, एक प्रोग्रामर नए घटकों को जोड़ सकता है या पुराने घटकों के व्यवहार को बदल सकता है।
   2.3। एक घटक को जोड़ने से मूल रूप से केवल नए उपयोग के स्थान पर जाँच की आवश्यकता होती है, और प्रोग्रामर के लिए न्यूनतम समय उत्पन्न होता है।
   2.4। कथन के अनुसार [१.६], एक नए कार्य के कारण एक घटक के व्यवहार में बदलाव के लिए नए उपयोग के स्थान पर और पुराने उपयोग के सभी स्थानों पर सत्यापन की आवश्यकता होती है, जो बयान [२.३] में स्थिति के साथ तुलना में अतिरिक्त प्रोग्रामर समय लागत बनाता है। एक प्रकाशित घटक के मामले में, इसके लिए संशोधित घटक का उपयोग करके सभी प्रोग्रामर के काम की आवश्यकता होती है।
3. सार्वभौमिक एल्गोरिदम और उनकी विशेषज्ञता की बातचीत में पैटर्न का वर्णन करने वाले विवरण:
   3.1। आधार घटक लिखने का अवसर है (नाम को आधार वर्ग के साथ सादृश्य द्वारा पेश किया गया है और संक्षिप्तता के लिए हम " आधार " शब्द का उपयोग करेंगे)। आधार केवल कुछ सार्वभौमिक एल्गोरिदम की सबसे महत्वपूर्ण विशेषताओं को पूरा करता है।
   3.2। एक विशेषज्ञता घटक लिखना संभव है (बाद में संक्षिप्तता के लिए हम " विशेषज्ञता " शब्द का उपयोग करेंगे)। विशेषज्ञता आधार के सार्वभौमिक एल्गोरिदम का पूरक है, जिससे यह उपयोग के एक विशेष क्षेत्र में लागू होता है।
   3.3। आधार , बयानों से निम्नानुसार है [3.1], [3.2], विशेषज्ञता की तुलना में कम जटिलता और कम आवेदन प्रतिबंध हैं ।
   3.4। बयान [1.7] के अनुसार, डेटाबेस से सार्वभौमिक एल्गोरिथ्म कोड के दोहराव के बिना विशेषज्ञता विकसित करना उचित है।
   3.5। डेटाबेस के उपयोग के स्थानों को सही ढंग से गठित विशेषज्ञता में परिवर्तन करने के बाद सत्यापन की आवश्यकता नहीं है।

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग कॉन्सेप्ट्स

मैं कोशिश करूँगा, उपरोक्त कथनों का उपयोग करते हुए, वस्तु-उन्मुख प्रोग्रामिंग की मूल अवधारणाओं का विश्लेषण करने के लिए। यह विश्लेषण अमूर्तता की अवधारणा को दरकिनार कर देता है, क्योंकि यह पहले से ही सार्वभौमिक एल्गोरिथ्म के निर्माण की विधि के औपचारिककरण में पहले ही वर्णित किया गया है।

कक्षा, वस्तु

ये OOP अवधारणाएं इन डेटा के साथ काम करने के लिए कुछ आंतरिक डेटा और विधियों के संयोजन द्वारा वर्णित एक विशेष प्रकार के घटक का उपयोग करने की व्यवहार्यता को सुदृढ़ करती हैं। समूह के सभी बयानों [1] और [2] का ओओपी में अनुवाद किया जाता है, जिसके लिए शब्द घटक को वर्ग की अवधारणा से बदल दिया जाता है।

एक ही समय में, पहली नज़र में, एक वर्ग और वस्तु के संबंध बयानों के समूह द्वारा समाप्त हो जाते हैं [3], जिसमें आधार को एक वर्ग की अवधारणा से बदल दिया जाता है, और किसी वस्तु की अवधारणा द्वारा कार्यान्वयन । इसके अलावा, कार्यान्वयन गतिशील है, अर्थात, कार्यक्रम के निष्पादन के दौरान परिवर्तनशील है।

कैप्सूलीकरण

" एनकैप्सुलेशन " की अवधारणा को दो "पक्षों" से माना जा सकता है।

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

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

यह उल्लेखनीय है कि " एनकैप्सुलेशन " की अवधारणा का जीव विज्ञान में एक सादृश्य है। यह पहली प्रक्रिया " सेल झिल्ली " के जैविक कार्यों के समान है।

विरासत

आधार + कार्यान्वयन के संयोजन के उपयोग के महत्व को सुदृढ़ करने के लिए " विरासत " की अवधारणा जारी है। इसके लिए, बयानों के समूह में [3] आधार के साथ मूल वर्ग के तरीकों की पहचान करना और कार्यान्वयन के साथ उत्तराधिकारी वर्ग के तरीकों की पहचान करना आवश्यक है ।

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

आधार + कार्यान्वयन बंडल का उपयोग करने के कई वैकल्पिक तरीके हैं। मैं आगे ऐसे तरीकों के उदाहरण दूंगा।

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

बहुरूपता

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

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

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

निष्कर्ष

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

लेख लिखने की प्रक्रिया में, प्रोग्रामिंग में उपयोग की जाने वाली अवधारणाओं के लिए जैविक उपमाएं पाई गईं। ये उपमाएँ एक सॉफ्टवेयर उत्पाद के विकास के तरीकों और जैविक विकास की कुछ प्रक्रियाओं की समानता के कारण दिखाई देती हैं।

IMHO, इन दो वैज्ञानिक क्षेत्रों पर एक साथ विचार करना उचित है। इस मामले में, एक उद्योग से दूसरे में कानूनों के हस्तांतरण को अंजाम देना संभव हो सकता है, और इस प्रकार सूचना प्रौद्योगिकी और जैविक प्रक्रियाओं के औपचारिक विवरण दोनों का विकास सुनिश्चित होता है।

आपका ध्यान के लिए धन्यवाद।

समीक्षा

मैं प्रतिक्रिया, सुझाव और सुझाव के लिए बहुत आभारी रहूंगा, क्योंकि वे मुझे इस क्षेत्र में काम के विकास की दिशा को समायोजित करने में मदद करते हैं।

संदर्भ

• विकी एल्गोरिदम का सामान्य सिद्धांत
• श्रृंखला का पहला लेख

बोरिसोवा द्वारा संपादित एम.वी.