10 वस्तु-उन्मुख प्रोग्रामिङ सिद्धान्तहरू प्रत्येक विकासकर्तालाई थाहा हुनुपर्छ

प्रायः म विकासकर्ताहरूलाई भेट्छु जसले SOLID सिद्धान्तहरू (हामी तिनीहरूको बारेमा यहाँ विस्तृत रूपमा कुरा गरे। — Transl.) वा वस्तु-उन्मुख प्रोग्रामिङ (OOP), वा तिनीहरूको बारेमा सुनेको छ, तर व्यवहारमा तिनीहरूलाई प्रयोग नगर्नुहोस्। यस लेखले विकासकर्तालाई उसको दैनिक कार्यमा मद्दत गर्ने OOP सिद्धान्तहरूको फाइदाहरू वर्णन गर्दछ। तिनीहरूमध्ये केही राम्ररी चिनिन्छन्, अरूहरू त्यति धेरै छैनन्, त्यसैले लेख दुवै शुरुआती र अनुभवी प्रोग्रामरहरूको लागि उपयोगी हुनेछ।

हामी सम्झाउँछौं: सबै Habr पाठकहरूका लागि - Habr प्रोमो कोड प्रयोग गरी कुनै पनि स्किलबक्स पाठ्यक्रममा भर्ना गर्दा १०,००० रूबल छुट।

Skillbox सिफारिस गर्दछ: शैक्षिक अनलाइन पाठ्यक्रम "जाभा विकासकर्ता".

DRY (आफूलाई नदोहोर्याउनुहोस्)

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

यदि कोडमा दुईवटा दोहोरिने खण्डहरू छन् भने, तिनीहरूलाई एउटै विधिमा जोड्नुपर्छ। यदि हार्डकोड गरिएको मान एक पटक भन्दा बढी प्रयोग गरिएको छ भने, यसलाई सार्वजनिक स्थिरतामा रूपान्तरण गर्न लायक छ।

कोडलाई सरल बनाउन र यसलाई कायम राख्न सजिलो बनाउनको लागि यो आवश्यक छ, जुन OOP को मुख्य लक्ष्य हो। तपाईंले युनियनको अति प्रयोग गर्नु हुँदैन, किनकि एउटै कोडले OrderId र SSN दुवैसँग प्रमाणीकरण पास गर्दैन।

इन्क्याप्सुलेटिङ परिवर्तनहरू

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

यदि तपाइँ Java मा लेख्नुहुन्छ भने, त्यसपछि पूर्वनिर्धारित रूपमा निजी विधिहरू र चरहरू असाइन गर्नुहोस्.

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

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

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

यहाँ यो सिद्धान्त उल्लङ्घन गर्ने कोडको उदाहरण हो।

यदि तपाइँ यसमा केहि परिवर्तन गर्न आवश्यक छ भने, यसले धेरै समय लिनेछ, किनकि इच्छित टुक्रासँग जडान भएको कोडको सबै खण्डहरू परिवर्तन गर्नुपर्नेछ।

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

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

SOLID सेटबाट अर्को सिद्धान्त। यसले भन्छ कि "त्यहाँ एउटा मात्र कारण छ जसले वर्गमा परिवर्तन निम्त्याउँछ।" कक्षाले एउटा मात्र समस्या समाधान गर्छ। यो धेरै विधिहरू हुन सक्छ, तर तिनीहरूमध्ये प्रत्येक मात्र एक साझा समस्या समाधान गर्न प्रयोग गरिन्छ। सबै विधि र गुणहरूले मात्र यो सेवा गर्नुपर्छ।

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

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

माथि एउटा कोड उदाहरण हो जहाँ AppManager EventLogWriter मा निर्भर गर्दछ, जुन बारीमा AppManager सँग जोडिएको छ। यदि तपाईंलाई सूचना देखाउनको लागि फरक तरिका चाहिन्छ भने, यो पुश, SMS वा इमेल होस्, तपाईंले AppManager कक्षा परिवर्तन गर्न आवश्यक छ।

DIP प्रयोग गरेर समस्या समाधान गर्न सकिन्छ। त्यसैले, AppManager को सट्टा, हामी एक EventLogWriter अनुरोध गर्छौं, जुन फ्रेमवर्क प्रयोग गरेर प्रविष्ट गरिनेछ।

DIP ले निर्भरता मोड्युल परिवर्तन गरेर सजिलैसँग व्यक्तिगत मोड्युलहरू अरूसँग बदल्न सम्भव बनाउँछ। यसले अरूलाई असर नगरी एउटा मोड्युल परिवर्तन गर्न सम्भव बनाउँछ।

विरासतको सट्टा रचना

कोड पुन: प्रयोग गर्ने दुई मुख्य तरिकाहरू छन्: विरासत र संरचना, जसका दुवैका आफ्नै फाइदा र बेफाइदाहरू छन्। सामान्यतया दोस्रो रुचाइन्छ किनभने यो अधिक लचिलो छ।

कम्पोजिसनले तपाइँलाई कक्षाको गुणहरू सेट गरेर रनटाइममा यसको व्यवहार परिवर्तन गर्ने क्षमता दिन्छ। इन्टरफेसहरू लागू गर्दा, बहुरूपता प्रयोग गरिन्छ, जसले थप लचिलो कार्यान्वयन दिन्छ।

जोशुआ ब्लोच द्वारा प्रभावकारी जाभाले पनि विरासतमा रचना छनौट गर्न सल्लाह दिन्छ।

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

SOLID टूलकिटबाट अर्को सिद्धान्त। यसले बताउँछ कि उपप्रकारहरू सुपरटाइपको लागि प्रतिस्थापन योग्य हुनुपर्छ। अर्थात्, सुपरक्लाससँग काम गर्ने विधि र प्रकार्यहरूले यसको उपवर्गहरूसँग समस्या बिना काम गर्न सक्षम हुनुपर्छ।

LSP एकल जिम्मेवारी सिद्धान्त र साझा जिम्मेवारी सिद्धान्त दुवै संग सम्बन्धित छ। यदि कुनै वर्गले उपवर्ग भन्दा बढी कार्यक्षमता प्रदान गर्दछ भने, पछिल्लाले यस सिद्धान्तलाई उल्लङ्घन गर्दै केही कार्यक्षमतालाई समर्थन गर्दैन।

यहाँ कोडको एक टुक्रा छ जुन LSP को विरोधाभास गर्दछ।

क्षेत्र (आयत r) विधिले आयतको क्षेत्रफल गणना गर्दछ। स्क्वायर कार्यान्वयन गरेपछि कार्यक्रम क्र्यास हुनेछ किनभने स्क्वायर यहाँ आयत होइन। LSP सिद्धान्त अनुसार, आधार वर्गका सन्दर्भहरू प्रयोग गर्ने कार्यहरूले अतिरिक्त निर्देशनहरू बिना व्युत्पन्न वर्गहरूको वस्तुहरू प्रयोग गर्न सक्षम हुनुपर्छ।

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

इन्टरफेस विभाजन सिद्धान्त (ISP)

अर्को ठोस सिद्धान्त। यसका अनुसार प्रयोग नगरिएको इन्टरफेस कार्यान्वयन गर्नु हुँदैन । यस सिद्धान्तको पालनाले अपरेटिङ तर्कमा परिवर्तनहरू गर्दा प्रणालीलाई लचिलो र रिफ्याक्टरिङको लागि उपयुक्त रहन मद्दत गर्दछ।

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

एक इन्टरफेस लेख्न गाह्रो काम भएकोले, काम पूरा भएपछि यसलाई कुनै पनि तोडफोड नगरी परिवर्तन गर्न चुनौती हुनेछ।

Java मा ISP सिद्धान्तको फाइदा यो हो कि सबै विधिहरू पहिले लागू गरिनुपर्छ, र त्यसपछि मात्र तिनीहरू कक्षाहरूद्वारा प्रयोग गर्न सकिन्छ। त्यसकारण, सिद्धान्तले विधिहरूको संख्या कम गर्न सम्भव बनाउँछ।

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

यहाँ नामबाट सबै कुरा स्पष्ट छ। यो सिद्धान्त लागू गर्नाले लचिलो कोडको सृजना हुन्छ जुन इन्टरफेसको कुनै पनि नयाँ कार्यान्वयनसँग काम गर्न सक्छ।

तपाईंले चर, फिर्ता प्रकारहरू, वा विधि तर्क प्रकारको लागि इन्टरफेस प्रकार प्रयोग गर्नुपर्छ। एउटा उदाहरण SubClass को सट्टा SuperClass प्रयोग गर्दैछ।

त्यो हो:

सूची नम्बरहरू = getNumbers();

तर होइन:

एरेलिस्ट नम्बरहरू = getNumbers();

यहाँ माथि छलफल गरिएको कुराको व्यावहारिक कार्यान्वयन हो।

प्रतिनिधिमण्डलको सिद्धान्त

एक सामान्य उदाहरण जाभा मा equals() र hashCode() विधि हो। जब दुई वस्तुहरू तुलना गर्न आवश्यक हुन्छ, यो कार्य ग्राहक एकको सट्टा सम्बन्धित वर्गलाई प्रत्यायोजित गरिन्छ।

सिद्धान्तको फाइदा यो हो कि त्यहाँ कोडको कुनै नक्कल छैन र व्यवहार परिवर्तन गर्न यो अपेक्षाकृत सरल छ। यो घटना प्रतिनिधिमण्डलमा पनि लागू हुन्छ।

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

Skillbox सिफारिस गर्दछ:

• व्यावहारिक पाठ्यक्रम "मोबाइल विकासकर्ता प्रो".
• अनलाइन पाठ्यक्रम लागू गरियो "पाइथनमा डाटा विश्लेषक".
• दुई वर्षे व्यावहारिक पाठ्यक्रम "म एक वेब विकासकर्ता प्रो हुँ".

स्रोत: www.habr.com