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

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

अनुस्मारक: सभी Habr पाठकों के लिए - Habr प्रचार कोड का उपयोग करके किसी भी स्किलबॉक्स पाठ्यक्रम में नामांकन करने पर 10 रूबल की छूट।

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

सूखा (अपने आप को दोहराएँ नहीं)

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

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

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

एनकैप्सुलेटिंग परिवर्तन

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

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

खुला/बंद सिद्धांत

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

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

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

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

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

एकल उत्तरदायित्व सिद्धांत (SRP)

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

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

निर्भरता उलटा सिद्धांत (डीआईपी)

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

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

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

वंशानुक्रम के बजाय रचना

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

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

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

बारबरा लिस्कोव प्रतिस्थापन सिद्धांत (LSP)

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

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

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

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

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

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

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

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

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

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

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

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

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

यही कारण है:

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

और नहीं:

ArrayList नंबर = getNumbers();

ऊपर जो चर्चा की गई है उसका व्यावहारिक कार्यान्वयन यहां दिया गया है।

प्रतिनिधिमंडल सिद्धांत

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

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

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

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

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

स्रोत: www.habr.com