ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के 10 सिद्धांत जो प्रत्येक डेवलपर को पता होना चाहिए

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

हम आपको याद दिलाते हैं: "हैबर" के सभी पाठकों के लिए - "हैबर" प्रोमो कोड का उपयोग करके किसी भी स्किलबॉक्स कोर्स के लिए पंजीकरण करते समय 10,000 रूबल की छूट।

Skillbox अनुशंसा करता है: जावा डेवलपर ऑनलाइन शिक्षा पाठ्यक्रम।

DRY (खुद को दोहराएं नहीं)

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

यदि कोड में दो दोहराए जाने वाले अनुभाग हैं, तो उन्हें एक विधि में जोड़ा जाना चाहिए। यदि हार्ड-कोडेड मान का एक से अधिक बार उपयोग किया जाता है, तो इसे सार्वजनिक स्थिरांक में परिवर्तित करने के लायक है।

कोड को सरल बनाने और इसके समर्थन को आसान बनाने के लिए यह आवश्यक है, जो OOP का मुख्य कार्य है। संघ का संयोजन भी इसके लायक नहीं है, क्योंकि समान कोड ऑर्डरआईड और एसएसएन दोनों के साथ सत्यापन पास नहीं करेगा।

परिवर्तन का पतन

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

यदि आप जावा में लिखते हैं, तो डिफ़ॉल्ट रूप से निजी विधियों और चर को असाइन करें ।

खुलेपन / निकटता का सिद्धांत

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

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

यहां कोड का एक उदाहरण है जो इस सिद्धांत का उल्लंघन करता है।



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

वैसे, खुलेपन-बंदपन एसओएलआईडी के सिद्धांतों में से एक है।

एकल जिम्मेदारी सिद्धांत (एसआरपी)

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



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

निर्भरता उलटा सिद्धांत (DIP)

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

डीआईपी का उपयोग करके समस्या को हल किया जा सकता है। इसलिए, AppManager के बजाय, हम एक EventLogWriter का अनुरोध करते हैं, जिसे फ्रेमवर्क का उपयोग करके पेश किया जाएगा।

DIP आपको निर्भरता मॉड्यूल को बदलते हुए आसानी से दूसरों के साथ व्यक्तिगत मॉड्यूल को बदलने की अनुमति देता है। यह बाकी को प्रभावित किए बिना एक मॉड्यूल को बदलना संभव बनाता है।

विरासत के बजाय रचना

कोड का पुन: उपयोग करने के दो मुख्य तरीके हैं - यह उत्तराधिकार और संरचना है, और प्रत्येक के अपने फायदे और नुकसान हैं। दूसरा आमतौर पर पसंद किया जाता है क्योंकि यह अधिक लचीला होता है।

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

यहां तक ​​कि जोशुआ बलोच द्वारा "प्रभावी जावा" विरासत के बजाय रचना को वरीयता देने की सलाह देता है।

बारबरा लिस्क प्रतिस्थापन सिद्धांत (एलएसपी)

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

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

यहां कोड का एक टुकड़ा है जो एलएसपी के विपरीत है।



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

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

इंटरफ़ेस पृथक्करण सिद्धांत (ISP)

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

अक्सर यह स्थिति तब होती है जब इंटरफ़ेस में एक साथ कई कार्यक्षमताओं होते हैं, और क्लाइंट को उनमें से केवल एक की आवश्यकता होती है।

चूँकि इंटरफ़ेस लिखना एक कठिन काम है, काम पूरा होने के बाद, बिना कुछ तोड़े इसे बदलना एक समस्या होगी।

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

इंटरफ़ेस के लिए प्रोग्रामिंग, कार्यान्वयन नहीं

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

चर, वापसी प्रकार, या विधि तर्क के प्रकार के लिए इंटरफ़ेस प्रकार का उपयोग करें। एक उदाहरण सुपरक्लास का उपयोग है, न कि सबक्लास का।

वह है:

सूची संख्या = getNumbers ();

और नहीं:

ArrayList नंबर = getNumbers ();

यहाँ ऊपर कहा गया है का एक व्यावहारिक कार्यान्वयन है।

प्रतिनिधि सिद्धांत

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

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



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

स्किलबॉक्स अनुशंसा करता है:

• व्यावहारिक पाठ्यक्रम "मोबाइल डेवलपर प्रो" ।
• एप्लाइड ऑनलाइन पाठ्यक्रम "पायथन में डेटा विश्लेषक" ।
• दो वर्षीय व्यावहारिक पाठ्यक्रम "मैं एक प्रो वेब डेवलपर हूं" ।